<Fallenou>
but it's cool if david or someone else does not want to recompile binutils :)
<lekernel>
code duplication is rarely cool
<lekernel>
at least not in the long term
<Fallenou>
sure, for the long term modified binutils is the way to go
<Fallenou>
if it can lower entry barrier for some developer who wants to help, just allowing not to compile a big tool like binutils, it can be a good idea
<Fallenou>
anyway I don't plan on using this kind of gnu as macro trick for "production" things, the dtlbtest() in the modified bios uses asm() inside C program and still needs modified gnu as
<Fallenou>
I suspect the freeze I had yesterday while testing dtlbtest occured because I was trying to write at physical page 0
<wpwrak>
aah !
<Fallenou>
I think there is some kind of protection against this in the SoC code
<wpwrak>
yo umet the NULL pointer trap :)
<Fallenou>
ahah
<Fallenou>
it's a tarp
<Fallenou>
I will redo the test today, mapping virtual page 1 to physical page 2
<Fallenou>
and pray harder
<lekernel>
Fallenou: I think you should instead disable this check (in system.v)
<wpwrak>
mmh, better go to RAM.
<Fallenou>
(instead of mapping virtual page 1 to physical page 0)
<larsc>
removing the trap shouldn't be to hard
<Fallenou>
wpwrak: oh I mean in RAM, || 0x4400
<wpwrak>
as far as i recall, the NULL pointer area is pretty large. ~128 kB, no ?
<lekernel>
yes
<Fallenou>
arg so several pages
<Fallenou>
ok will check
<wpwrak>
RAM is above the NULL pointer trap area
<Fallenou>
ah yes so it was not the trap :/
<Fallenou>
I was trying to access 0x44000000
<wpwrak>
if you really want to write to NOR, i can also walk you through that process. but it's a bit messy.
<Fallenou>
no no let's keep it siple :)
<Fallenou>
simple*
<wpwrak>
(because of locking and because word writes can only change 1 -> 0, so you need to erase the block to get back to 1)
<wpwrak>
yeah, RAM is simple and symmetric :)
<Fallenou>
the simpler, the better
<Fallenou>
to reduce murphy effect as much as possible :p
<wpwrak>
yeah, the hard part is the proof of concept. once you have the whole story work at least once, all the rest is incremental
<xiangfu>
kristianpaul, Hi
<Fallenou>
yes
<lekernel>
let's say the FPGA design makes it look simple and symmetric from the CPU point of view. but it'd have been actually simpler to use NOR at the underlying medium than DDR *g*
<wpwrak>
you could have added an SRAM chip to work around that issue ;-)
<lekernel>
xiangfu: by the way, the VGA core doesn't output sync-on-green information. you may want to try to add it (just XOR of HSYNC and VSYNC on the appropriate pin of the ADV7125)
<lekernel>
wpwrak: actually I thought early about using SRAM for system memory, but it would cost more than $100 for 4MB
<wpwrak>
yeah, SRAM is evil
<wpwrak>
(sync on green) is that ever needed for VGA ?
<lekernel>
even though the chip area is only about 6 times larger than DRAM for a given capacity, the cost per bit is much higher
<wpwrak>
may be the smaller volume
<lekernel>
yes, sure
<Fallenou>
6 transistors per bit, instead of 1 capa ?
<lekernel>
instead of 1 capa + 1 transistor
<Fallenou>
(+ 1 transistor)
<lekernel>
(sog) in theory no, but who knows how they designed that projector
<roh>
lekernel: could you capture vga if provided on rca with sync on green?
<lekernel>
and all computers I know of have sog
<lekernel>
roh: with the 7181C yes
<lekernel>
up to 1024x768
<roh>
nice. that could actually be really useful.
azonenberg has joined #milkymist
<lekernel>
assuming, of course, that we have a proper FPGA and software design
<roh>
kinda vga-genlocking with effects
<azonenberg>
lekernel: yeah, SDRAM is nasty stuff
<azonenberg>
whether DDR or not
<lekernel>
at least SDR uses only a complex control algorithm
<azonenberg>
lol
<lekernel>
that is, if you want performance - with autoprecharge and a simple FSM, it's not too bad
<azonenberg>
Btw, roughly how big is the ethernet MAC you guys are using? In terms of slices
<lekernel>
DDR uses both a messy algorithm and super-messy I/Os
<lekernel>
and it's getting worse with each generation - the only thing that went better was the removal of some off-chip terminations
* azonenberg
wonders why we cant just talk to ram over LVDS
<azonenberg>
have like 16 source-synchronous DDR LVDS pairs clocked at a GHz or so
<lekernel>
DDR4 will be using some new "POD12" signaling... the JEDEC spec is already published, haven't looked at it yet
<azonenberg>
is it compatible with existing, say, FPGAs?
<lekernel>
I guess not :)
<azonenberg>
not that the hard MCBs etc will work
<azonenberg>
And not that it matters to me since i dont yet have board fab capabilities to do BGAs that fine
<lekernel>
though maybe you can hack it if you write the IOB frames yourself instead of using the preset (LVCMOS33, ...) ISE settings
<azonenberg>
the newest RAM i can handle on my process is DDR in TSSOP since the BGA versions of DDR2/3 are too small
<azonenberg>
pitch wise
<lekernel>
but that would need some very low level reverse engineering
<azonenberg>
And i have to use FTG256 or FGG484 FPGAs
<azonenberg>
CSG324 is too fine pitch for the fab's design rules
<azonenberg>
top metal, roughly gigapixel resolution
<lekernel>
the IOB frame isn't the hardest... on S6 it's just one big shift register, with a fixed number of bits (and the same format) for each I/O site
<lekernel>
well, CPLDs and FPGAs have wildly differing architectures, I'm not sure if you'll learn anything useful for FPGAs by starting with CPLDs
<azonenberg>
no, i want to learn abourt xilinx's bitstreams in general
<azonenberg>
the next will be spartan3a
<azonenberg>
i have some i dont mind killing so i may decap and image them to study the die layout and see how accurately it matches the planahead / fpga editor views
<lekernel>
the bitstream format is semi-trivial, what matters is the internal structure of the interconnect
<azonenberg>
Yeah
<lekernel>
you can get a complete map of it using xdl
<azonenberg>
I may look at an original 4000 series first
<azonenberg>
those are 350nm and big enough to do transistor-level RE of with the equipment me and my collaborators have
<lekernel>
now it'd be interesting to do some graph analysis on it, classify tiles, find regularities, etc.
<azonenberg>
Yeah
<azonenberg>
Xilinx devices are high on our hit list
<azonenberg>
but we're working our way up
<azonenberg>
the CPLD came first since i had one around i didnt mind killing and it was only $1.60
<azonenberg>
plus it was a 350nm process whcih is big enouhg to fully image optically
<lekernel>
I have a box of 64x XC4036 which you can kill if you want
<azonenberg>
i dont need that many lol
<azonenberg>
Let me ask my friend if he has any yet
<azonenberg>
he may have some xc4000 series already
<azonenberg>
just not decapped yet
<azonenberg>
we have so many specimens its not even funny, the bottleneck is lab time
<lekernel>
actually the xc4000 arch is documented in xilinx patents
<azonenberg>
he only has so many hours a day to work on it
<lekernel>
(iirc)
<azonenberg>
Nice
<azonenberg>
Do you know if there are any patent concerns re writing FOSS toolchains btw?
<azonenberg>
iow, if we do not implement an FPGA using their architecture
<azonenberg>
but only target theirs with our software
<azonenberg>
a) do they have any legal basis to complain
<azonenberg>
b) do you think they would care, or welcome it
<lekernel>
check US5907248
<azonenberg>
Too sleepy to do technical reading but will check when i'm awake
<lekernel>
I think they won't care, especially if it's for the obsolete xc4000
<azonenberg>
i meant for s3a/s6
<wpwrak>
my guess is that they will fight you
<azonenberg>
4000 is EOL'd so much they dont even support it in currnet ISE
<azonenberg>
they wont care about that
<azonenberg>
I just wonder if it'd prove impossible to get a toolchain for current generation architecture
<wpwrak>
but there may be little they can do once the cat's out of the bag :)
<azonenberg>
why must FPGAs be so secretive? Intel documents their instruction set
<wpwrak>
besides some legal revenge killing, of course
<azonenberg>
and welcomes third party compilers
<lekernel>
no, it's not impossible
<azonenberg>
so why cant fpga vendors do the same
<lekernel>
it's just that no one cares
<wpwrak>
because being open takes courage
<lekernel>
all hackers want is raspberry pi's and arduinos
<wpwrak>
lekernel: there's more to it. by giving out information, you may give a competitor a small advantage. or at least you can imagine you may.
<wpwrak>
lekernel: also, any information you provide can and will be used against you by patent trolls
<lekernel>
but it's not as if the bitstream format was *so* hard to understand
<lekernel>
and as I said, you can find plenty of resources about the architecture (xdl, patents, ...)
<wpwrak>
and then there's design protection. customers may not appreciate seeing their preciousss IP exposed to prying eyes
<lekernel>
yes, that too... and also they said they want to keep the toolchain under control to limit tech support problems
<wpwrak>
corporate psychosis at its best ;-)
<wpwrak>
i'm sure intel tech support has no end of trouble because of all those pesky gcc users ;-)
<lekernel>
well... seems they're happy this way, with big telcos and government agencies as their main customers
<wpwrak>
but what would happen is that, once the cat's out of the bag, the FPGA world will change forever. and then they would have to consider adapting. and that is an effort. beancounters don't like extra efforts.
<lekernel>
I'm not sure if it'll make such a large difference in the "FPGA world"
<lekernel>
imagine we publish a free toolchain tomorrow, what will happen?
<lekernel>
academics will probably use it - rather small impact
<wpwrak>
if it's good, it may see widespread use
<lekernel>
4 hackers will jump into FPGAs - negligible impact
<wpwrak>
also, people will then include support by that toolchain in their purchase decisions
<lekernel>
and I guess their main (conservative) customers will keep using ISE
<wpwrak>
i think there's more untapped potential in fpga than just 4 hackers
<wpwrak>
oh sure. they'll stick with the proprietary stuff until they reach retirement age.
<wpwrak>
but the kids fresh from university who replace the geezers will have different ideas
<wpwrak>
and there are a number of rather interesting research opportunities waiting there as well
<wpwrak>
like accelerating that excessively sluggish synthesis process. i'm sure a quick and dirty synthesis could be done in a negligible fraction of the time the current tools use
<wpwrak>
maybe 50% and twice the size of the "optimized" design. who cares if it's inefficient during development ?
<wpwrak>
50% the speed
<lekernel>
oh, totally. and direct lava-to-bitstream sounds quite interesting too :)
<wpwrak>
and then there's partial reconfiguration
<wpwrak>
and then, the next big leap, C to FPGA. for inner loops. and yes, you probably want to use llvm for that project ;-)
<wpwrak>
so yes, i think there's an exciting world waiting on the other side of that wall of secrecy
<lekernel>
it's not a wall of secrecy, but rather a wall of indifference
<lekernel>
just like the one the M1 has hit
<wpwrak>
i think there's more to it. i don't expect them to be happy when you mess with their ecosystem.
<wpwrak>
M1 still needs to mature a bit. it's not ready for the masses anyway
<wpwrak>
right now, it's at the level where hackers can use it. now intersect the hacker population and the VJ population. pick from this set these who have a disposable USD 500. how huge a crowd of potential customers do you see ? :)
<wpwrak>
things will get better once we're out of the hacker niche
<wolfspraul>
milkymist has not hit a wall of indifference imho
<wolfspraul>
if you zoom out and compare it with a calm state of mind, you realize what a bold and demanding project it is
<wolfspraul>
it's like asking people to join some quantum computing project. would you?
* lekernel
would
<wolfspraul>
I feel we increasingly get our fair chance to talk about Milkymist
<wpwrak>
oh yes. the message is coming together.
elldekaa has joined #milkymist
<lekernel>
oh, yes, it's getting better, but still pretty bad imho
<wpwrak>
(showwx+) someone really ought to write that M1 logic analyzer. the platform is considerably more capable than those usb LAs with tiny buffers.
<wpwrak>
lekernel: when the marketing message hits the masses, you want to be prepared to deliver. that means the software has to be in great shape, you must have stock, and you must be ready to produce more quickly.
<wpwrak>
nothing is worse than getting a lot of orders you can't fulfull
qi-bot has joined #milkymist
roh has joined #milkymist
stekern has joined #milkymist
<wolfspraul>
I hope xiangfu can first go through a number of educated guesses blindly (for the vga signal problem)
<wolfspraul>
then we see
<wolfspraul>
(literally :-))
<xiangfu>
lekernel, whether the fpga could send something that could permanently damage the projector? is that possible?
<wpwrak>
btw, how good is the image quality of that laser projector ? can it really handle large surfaces ?
<xiangfu>
wpwrak, 800x480.
<lekernel>
xiangfu: no, you won't damage the projector
<wpwrak>
xiangfu: i mean square-meters :)
<lekernel>
800x480? can it accept 4:3?
<wpwrak>
lekernel: ... unless the projector's firmware has bugs :)
<xiangfu>
70"--100" from the
<lekernel>
xiangfu: when you set your laptop to 640x480, does it work?
<xiangfu>
lekernel, it's support 640x480.
<xiangfu>
wpwrak, the bigger diagonal is 70" -- 100" from the manual. with 100% complete darkness.
<xiangfu>
lekernel, yes. it works fine with laptop.
elldekaa has joined #milkymist
<wpwrak>
xiangfu: (manual) yes ... and in real life ? manuals don't always tell the truth ;-)
<xiangfu>
wpwrak, sorry, didn't test that yet.
<wolfspraul>
the first reason I like this projector is that we can reproduce a vga signal bug that may be more common than we currently think
<xiangfu>
just test a little. I think 4mx5m is still ok for low resolution picture. but it doesn't work with m1. so don't know if it ok with m1 rendering.
<wolfspraul>
I've heard of 2 cases (kristian paul and christophe), and from the very limited set of people that we hear back at all, that's a lot!
<wolfspraul>
so I'm happy we can reproduce this bug now, and hopefully there is actually only one bug, not several...
<wolfspraul>
thank you laser projector :-)
<wpwrak>
xiangfu: 4x5m sounds pretty good
<lekernel>
xiangfu: since it doesn't work with any of the M1 video modes, i'd start with adding sync on green
<xiangfu>
lekernel ok. will try that tomorrow. then report back.
<GitHub175>
[migen/master] Fix syntax errors and other stupid problems - Sebastien Bourdeauducq
<lekernel>
grmbl, xst is too stupid to infer block-rams with byte-wide write enables for data widths > 32 bits
<wpwrak>
what does it give you instead ?
<lekernel>
time to start a "final code transforms to work around synthesizer limitations" library in migen, I guess
<lekernel>
distributed RAM, which fills the FPGA
<wpwrak>
sweet :)
<wpwrak>
perhaps some of these limitations simply come from a desire to sell larger and more expensive chips ? ;-)
<larsc>
what do they say? don't mistake incompetence for intent ;)
<wpwrak>
wasn't it "don't attribute to incompetence that which can be adequately explained by malice." ? :)
<larsc>
or maybe it was the other way around
<wpwrak>
that depends largely on whom you're talking about :)
<Fallenou>
lekernel: oh that's why I guess in lm32_dcache.v they put if (dmem_addr_width < 11) then one block of 32 bit width else blocks of 8 bit width
<wpwrak>
larsc: yes yes, i know :) i intentionally turned it around, because it seems to make sense in some contexts. certain people appear to have a compulsion to act evilly. as if they were the stereotypical villain in a movie.
<lekernel>
let's see with ISE 13.4 ... chances are low, but...
<larsc>
wpwrak: xilinx is a strategical partner of the group i'm working in. i could tell you stories... ;)
<lekernel>
seems their download server is down
<wpwrak>
larsc: we should have a qi-hw conference some day. then i could see how many beers it takes to get such stories out of you ;-)
<GitHub81>
[migen/master] corelogic: support reverse in displacer/chooser - Sebastien Bourdeauducq
<GitHub81>
[migen/master] bus/wishbone2asmi: cache hits working - Sebastien Bourdeauducq
<larsc>
wpwrak: hehe
<lekernel>
wpwrak: this summer in Berlin, if we can sort out a room
<GitHub109>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/oIYKXA
<GitHub109>
[milkymist-ng/master] Include Wishbone to ASMI bridge - Sebastien Bourdeauducq
<lekernel>
seems it's quite hard to get anything else than a kiezparty done in this city. getting conference rooms was easier in France ...
elldekaa has joined #milkymist
<wpwrak>
lekernel: have you pinged the folks at ccc ?
<wpwrak>
lekernel: and we don't only need a room but also travel money :)
<lekernel>
the ccc is paying a lot of money to the congress center (that's why the tickets are a bit expensive)
<lekernel>
i'd rather spend that money on speaker travel expenses
<wpwrak>
hmm. how big do you plan to make this ? i was more thinking of them helping with finding something small. they must have smaller events, too.
<lekernel>
if all else fails, we'll do it somewhere else
<lekernel>
300-500 people I think
<wpwrak>
that's pretty big
<wpwrak>
e.g., at its peak, OLS had ~650 attendees. that's with 3-4 parallel sessions etc.
<wpwrak>
and they needed about a year to prepare the event. not entirely sure about the team size. something around ten people.
<wpwrak>
another useful contact could be the organizers of linux-kongress
<lekernel>
not so big... the three zero-budget events I have organized had 150-200, and that was without too much publicity effort
<wpwrak>
well, there, the location changes from year to year and so do the local organizers. but there you'll find people who have experience with medium-sized conferences.
<wpwrak>
150-200 sounds manageable. and you've done this before. very good. i was a bit worried about that :)
<lekernel>
I'm pretty confident we can reach 300 with a very exciting programme and better publicity
<wpwrak>
it's not so much a question of getting a lot of people interested but one of crowd management :)
<lekernel>
yes, I've done it before, but (1) without budget, which also means less work (2) with fewer attendees (3) with less problems with finding a venue
<lekernel>
but no challenge no fun, right? :)
<wpwrak>
yeah ;-)
<wpwrak>
the budget complicates things. raises attendee's expectations. and you'll probably also have to do some paperwork for taxes and such
<lekernel>
oh, I have a professional accountant on the team :-)
<wpwrak>
heh ;-)
<lekernel>
the #1 problem we have at the moment is that every single venue we have contacted is either very expensive, very dismissive, or too small
<wpwrak>
what do you mean with dismissive ? people who are difficult to negotiate with ? or just a dump ?
<lekernel>
people not answering emails or being evasive... we've contacted the deutsches technikmuseum and they really are a pain
<wpwrak>
sometimes it helps to just call them :)
<lekernel>
oh, sure, we did
<lekernel>
4 times already, plus two visits in person
<lekernel>
and we'll call them already tomorrow
<lekernel>
s/already/again
<wpwrak>
so it's not a lack of effort from your side
<lekernel>
no... I don't quite know what's on their mind, hopefully we'll know more tomorrow
<lekernel>
it'd be a great location if we can establish a good contact with them
<wpwrak>
have you considered a university ? they have lots of empty rooms during the summer vacation
<lekernel>
in progress, but slow. and it seems they do charge for the rooms, though I don't know how much.
<wpwrak>
you'll probably need some inside support. maybe guug (linux-kongress) can help you find a contact. or warn you of places that are a waste of time
<lekernel>
when I did it at a French uni in 2010 I got three rooms for free with something like 2 meetings + 1 phone call + 1 letter written in 10 minutes
<lekernel>
seems things aren't so simple here :(
<wpwrak>
german thoroughness :)
<wpwrak>
wolfspraul: the weird little corner of the jtag board does actually have a use: it helps you to align the board with the connectors. otherwise, you would have to "feel" for correct alignment. sort of fumblish.
<wolfspraul>
can m1 know how much power each usb socket consumes?