kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
<lekernel_>
hmm... maybe use some bytecode hacks instead
<wpwrak>
ah, i see that you're going very deep into python :) (and no, i have no idea. that's way deeper than i ever went)
<larsc>
i've been playing a bit with networkx and fragment operator trees. this is the dependency graph for the simple gpio example: http://metafoo.de/depgraph.png - and this is the same graph if the d_o signal is not connected: http://metafoo.de/depgraph2.png
<larsc>
red nodes are completely unused and can be removed, green nodes are used but are sort of const
<lekernel_>
larsc: verilog synthesizers already take care of such simplifications
<lekernel_>
so I wouldn't include such things in Migen... now, of course, it can be useful to build a FHDL simulator, or just to play with graphs
<larsc>
lekernel_: i know
wolfspraul [wolfspraul!~wolfsprau@p5B0AA963.dip.t-dialin.net] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
<Fallenou>
lekernel_: when you ship a bitstream, all timing constraints are met ?
<Fallenou>
I got the first one "not met" : TS_sys_clk_dcm = PERIOD TIMEGRP "sys_clk_dcm" TSclk50 / 1.6 HIGH 50%
<Fallenou>
on the SETUP line it says "21" in the column "Timing Errors"
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
<whitequark>
lekernel_: (bytecode hacks) that's what I do for at least last month. ruby and AS3 bytecode hacks. maybe I can help.
<whitequark>
what do you want to achieve?
<lekernel_>
Fallenou: yes, all timing constraints are met
<lekernel_>
if you have made modifications (however minor) it can break timing
<lekernel_>
whitequark: get from a function the name of the variable in which its return value is stored by the caller
<lekernel_>
mwalle: btw, did you continue working on micromonitor? for the -NG SoC I'll try to keep the amount of software shipped to a bare minimum... so the 1st stage bootloader would typically get the SDRAM to work, provide functions to debug it when it does not, and simply jump to another binary (2nd stage) in the flash
<lekernel_>
there's u-boot too... with fancy stuff like USB booting
<whitequark>
lekernel_: impossible in general case
<whitequark>
in a non-general one (that is, when the function is actually assigned to a local variable)... well
<whitequark>
I have a static analysis framework which does exactly what you want
<lekernel_>
it doesn't have to work in 100% of the cases, just extract enough names for the generated verilog to be readable
<lekernel_>
the program would still be correct if the function always returned an empty strings, only the generated code would be a mess
<lekernel>
oh, theobroma has ported u-boot to lm32... I wonder if they at least got that one right
<wpwrak>
if it's u-boot, it's already wrong ;-)
<wpwrak>
u-boot is an incredible waste of time. get sucked into it and you'll spend the next year or so turning u-boot into a little operating system, with its own drivers, etc.
<wpwrak>
there's always one more cute feature you could add to it. and it seems so easy. so you do it. then you realize it's not easy, e.g., because they driver they forked from linux really needs locking but you don't have that. but since you already started, ...
<whitequark>
lekernel: how fast do you need that to be implemented?
<whitequark>
I can add python bytecode support next week
<lekernel>
whitequark: it should be in the python code itself, and actually already working... :)
<lekernel>
it's not really a problem of speed, but more avoiding tons of external dependencies
<lekernel>
I have something that works reasonably well in just ~20 lines of code atm
<lekernel>
wpwrak: so, what nice bootloader would you recommend?
<lekernel>
keep the current one?
<wpwrak>
yeah. keep booting as simple as possible. it's not as if the boot loader was a place where you'd want to spend time, grow roots
<lekernel>
yes, but it's nice to have things like network booting, or USB stick booting
<wolfspraul>
Werner is a long-time known u-boot hater :-) (Werner, you should be proud about that attribution)
<wpwrak>
depend on how much you use them :) i hardly ever used network boot. from a workflow point of view, nor boot is almost as good. plus, the m1 is in a repeatable state. (which can of course be undesirable in some cases)
<wolfspraul>
u-boot suits itself well for a development board, or when at the beginning of a product development, you don't know yet very well in which direction you want to take the final product (which boot options, etc)
<wolfspraul>
it's a tool and admission of cluelessness
<wpwrak>
wolfspraul: maybe you can call me "Werner the destroyer" ? ;-)
<wolfspraul>
wait I try to put this a little in perspective
<lekernel>
I use netboot all the time for software development... I even have the NOR cleared on my dev M1 so that it tries to boot from the network only
<wolfspraul>
it does serve some functions, you cannot see it all so static imho
<wolfspraul>
so it's like a swiss-army-knife
<wpwrak>
well, u-boot is sort of the operating system before you have an operating system
<wolfspraul>
if you have a laser sharp idea how the final product should be, you can indeed bypass it and just write your "100 lines only do nothing" bootloader
<wolfspraul>
but watch out, over the years it may grow into thousands and more lines still
<wolfspraul>
all depends on your discipline
<wolfspraul>
wpwrak: yes but there is not only long-term
<wpwrak>
just ... since u-boot isn't your final destination anyway, why spend time adding features there and not in the OS you need in the end ?
<wolfspraul>
there are also short-term goals, and sometimes at some point A in a development project, there is just a lot of uncertainty
<wolfspraul>
u-boot can help
<lekernel>
the use cases I see for u-boot is (1) boot from NOR (2) boot from network for sw development (3) boot from USB or memory card to easily try things like linux distros, if those come out someday (ditto USB drive and stronger memory card support ofc)
<wolfspraul>
but in any serious product, indeed, sooner or later it has to be kicked out again because it becomes a drag as the product and boot process gets optimized
<wpwrak>
don't forget that - when using linux - you can always use kexec to boot something else
<wolfspraul>
that is my experience
<wolfspraul>
yes, exactly. easily try the unknown.
<wolfspraul>
for that kind of thing, there's a swiss army knife called u-boot
<lekernel>
wpwrak: so, should we simply initialize the SDRAM and immediately jump to the kernel?
<wolfspraul>
and for that purpose, it does have value
<wpwrak>
lekernel: that's what i'd do
<wolfspraul>
when people see that there is u-boot on a platform, they have a starting point they know
<wolfspraul>
yes, I wouldn't waste time with u-boot either
<wolfspraul>
but watch out, over time those "few lines" will grow :-)
<wolfspraul>
guaranteed, mark my words :-)
<lekernel>
wolfspraul: if it's not messy to port (but wpwrak tells us otherwise) u-boot would be a good choice
<wolfspraul>
u-boot is a bloated mess
<wolfspraul>
it's a swiss army knife, can do everything, but not really good at anything
<wpwrak>
i participated only in one effort that brought linux from zero (minus CPU arch support) on a device, and that was on the psion s5. and there we didn't linger for more than a few days (development effort) at the boot loader.
<wolfspraul>
huge huge amount of sources
<wpwrak>
nobody had any problem with that :)
<wolfspraul>
if a newbie runs into the "milkymist platform", the fact that there is u-boot there may give them some comfort. that's the biggest value of u-boot imho.
<wolfspraul>
if Milkymist becomes part of any serious product, u-boot will be optimized away as part of the productization process
<wpwrak>
lekernel: wolfgang and i both had some horrifying experiences with u-boot at openmoko :)
<wolfspraul>
yes but I'm a little more nuanced as to u-boot's value
<wpwrak>
wolfspraul: how many manyears do you think where ultimately sunk into it ? :)
<wpwrak>
s/where/were/
<wolfspraul>
yes but like I said. if I do a development board for some big firm, I want u-boot on it, u-boot is in my checklist
<wolfspraul>
because there is nothing really I can optimize the devel board for anyway
<wpwrak>
oh, if someone else provides it, why not
<wolfspraul>
so let's just get u-boot on it
<wolfspraul>
see my point?
<wolfspraul>
that's a value too
<wpwrak>
of course, i'd even more want to see a linux kernel for it :)
<wolfspraul>
a tool for the clueless (hopefully 'yet')
<wolfspraul>
exactly as lekernel said "run some distro"
<wpwrak>
i'll pick the linux kernel :) in u-boot, you can get away with too many things that the code there doesn't prove much
<wolfspraul>
which one? don't know ;-)
<wpwrak>
distro doesn't matter. you need the kernel :)
<wolfspraul>
if it's easy to just jump to a Linux kernel, I think that's the better thing for milkymist right now
<lekernel>
alright, let's keep the current BIOS then
<wolfspraul>
I'm just a little nicer to u-boot that's all
<lekernel>
so far no one has complained about it :)
<wolfspraul>
u-boot is so bloated...
<wolfspraul>
it carries this ever-increasing list of supported historical devel boards with it
<wpwrak>
you can spin incredibly small systems from almost any distro. see my "myroot" at openmoko. it's very little work. and it can go a very long way.
<wolfspraul>
I think u-boot as a project is doing quite well btw
<lekernel>
if it's done properly, it shouldn't be a problem. but you seem to be telling me it's not ...
<wolfspraul>
growing like mushrooms
<wolfspraul>
lekernel: u-boot is good for devel boards
<wolfspraul>
for a product? no
<lekernel>
by the way, I wonder how to get the linker to place the variables of one part of the source into SRAM and the rest in SDRAM .. hmm
<larsc>
aand u-boot has serious code quality issues
<wolfspraul>
fully agree
<wpwrak>
plus it's full of regressions becuase nobody looked after the drivers after forking them from linux
<wolfspraul>
it's a huge pile of garbage
<wolfspraul>
but flexible, you can build *everything* out of those parts, right? :-)
<lekernel>
the idea is to add some on-chip SRAM and rewrite libhpdmc in C because it's going to become more complicated with things like PHY calibration sequences
<wpwrak>
lekernel: you can probably put the variables into named linker sections and then send these sections to specific addresses
<wpwrak>
(in a linker script)
<whitequark>
lekernel: (python code) ah ok, not precisely my domain then.
<wpwrak>
wolfspraul: i think some of the appeal of u-boot comes from the close source world. in the old days, the "monitor" was the last simple thing you had in your system. after that, you'd boot some closed source monstrosity like solaris or aix, and had no control of what was going on at a lower level.
<wpwrak>
wolfspraul: similar for embedded systems. you usually didn't have the sources, even if it was something simple like pSOS or such
<wpwrak>
wolfspraul: so of course, if you're in such a scenario and need to debug some low-level issues, the monitor (aka u-boot) would be where you like to make your camp.
<wpwrak>
wolfspraul: now in the modern open source world, this doesn't matter. you're just as much empowered under rtems, linux, or bsd as you as in u-boot. most likely, even more so.
<wpwrak>
s/you as/you are/
dvdk [dvdk!~dvdkhlng@g225041073.adsl.alicedsl.de] has joined #milkymist
<wpwrak>
but of course, not everyone has arrived in the modern age yet. even though it has started some 20 years ago :)
<GitHub121>
[migen/master] examples/wb_intercon: update to new APIs - Sebastien Bourdeauducq
<lekernel>
hi dvdk
<dvdk>
trying to get a copy of the MM1 schematics, but so far no luck.
<wpwrak>
oh, 1-2 weeks ago, it must have my 20th anniversary of linux :) i started when a friend told me 0.12 was finally self-hosting (didn't need minix to run)
<dvdk>
qi-hardware has a tarball but no pdf, and I'm too lazy to install any schematic software
<lekernel>
wpwrak: but that would mean writing a directive for each variable... which would be easily forgotten, leading to frustrating bugs
<lekernel>
wpwrak: specifying the object filenames in the linker script is both possible (it seems) and safer...
<larsc>
wpwrak: one of my favourite phrases currently is "it's not 1990 anymore" ;)
<wpwrak>
lekernel: yes .. there may be ways to have wildcards for entire object files. not sure, though. i never went very deep into linker scripts.
<wpwrak>
lekernel: if all else fails, you could just extract the names from the object file with nm and issue explicit directives ;-)
<wpwrak>
(with a script)
<wpwrak>
larsc: hehe, very true ;-)
<dvdk>
wpwrak: thanks, anybody mind if i put a direct link into the qi-hw/mm1 wiki page?
<lekernel>
no, just do it
<wpwrak>
dvdk: i'm sure the lynch mob complete with torches and pitchforks will be at your doorstep any minute now :)
* dvdk
is running from the lynch mob
<dvdk>
oh my god, pitchforks!
<dvdk>
hmm, schematics aren't really informative, if everything is hidden inside the fpga block :)
<wpwrak>
ah, took me almost two months until my first post on linux-activists (march 11; i must have started with 0.12 around january 20)
<wpwrak>
"schematics aren't really informative, if everything is hidden inside the microcontroller" ;-)
<wolfspraul>
dvdk: hi David, and welcome to Milkymist!
<larsc>
wpwrak: and in another 20 years you'll look back onto your first post to the milkymist mailinglist ;(
<wolfspraul>
yes sorry, it's messy :-)
<wpwrak>
and the next day i already felt bold enough to post a mail with the subject pompously starting with "WARNING:". gee, what a little prick i was ;-)
<wolfspraul>
wpwrak: interesting idea, and yes, could be. [u-boot as last camp post before closed blob] I still think it's a good tool for the undecided, but I've made my point and nothing to add. for m1 if we can optimize it away right now, great. it will be optimized away sooner or later anyway.
<lekernel>
Founded in 1992, the cornerstone of Chipworks is our focused, energetic team of semiconductor and patent savvy engineers.
<wpwrak>
and of course, it accumulates rounding errors that throw it off badly. also, in milkdrop the modulo is on integers, so we should add an f2i i2f pair for each argument, making the code sequence even longer
<lekernel>
wpwrak: yeah, the current implementation of % is quite an experimental hack :)
<wpwrak>
where do i send the job application ? i think i have some very clear opinions on patents (-:C