lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
jevin has joined #milkymist
playthatbeat has quit [*.net *.split]
zumbi has joined #milkymist
zumbi is now known as Guest37274
playthatbeat has joined #milkymist
Guest40180 has quit [Ping timeout: 245 seconds]
bkero has quit [Ping timeout: 245 seconds]
sh4rm4 has joined #milkymist
bkero has joined #milkymist
ChanServ has quit [*.net *.split]
larsc_ has joined #milkymist
larsc has quit [*.net *.split]
ChanServ has joined #milkymist
hypermodern_ has joined #milkymist
hypermodern_ has left #milkymist [#milkymist]
azonenberg has quit [Read error: Operation timed out]
kyak_ is now known as kyak
lekernel has joined #milkymist
kilae has joined #milkymist
bhamilton has joined #milkymist
lekernel has quit [Ping timeout: 256 seconds]
lekernel has joined #milkymist
kyak has quit []
<lekernel>
so next MM board will likely have the JTAG/serial builtin. wpwrak will be happy ;)
<lekernel>
and less slow -3 speed grade FPGA
kyak has joined #milkymist
kyak has quit [Changing host]
kyak has joined #milkymist
larsc_ is now known as larsc
bhamilton has quit [Quit: Leaving.]
<Fallenou>
lekernel: Do you know how do they manage to do different speed grades?
<Fallenou>
they use different cell tecnologies?
<Fallenou>
+h
mumptai has joined #milkymist
bhamilton has joined #milkymist
<Fallenou>
12:15 < lekernel> and less slow -3 speed grade FPGA < you mean with a kintex-7 ? or a Spartan-6 with a better speed grade? ( is -1 better than -3 for S6?)
<lekernel>
everything using modern semiconductor processes has wide process/voltage/temperature variation
<Fallenou>
oh, ok, so they design with the "fastest" goal in mind
<Fallenou>
and then they attribute "lower" speed grades to the one not capable of reaching that goal after testing
<Fallenou>
because of manufacture problems
<lekernel>
the slowtan6 philosophy is generally to dump this mess on the user, e.g. the programmable IO input delays have a "maximum" delay, and then "the minumum delay is typically 1/3 the maximum delay" - deal with that
<Fallenou>
ahah :)
<lekernel>
or the high speed IO terminations are specified between ~10 ohm and ~50 ohm - I wonder if anyone can actually use that...
<Fallenou>
wow
<lekernel>
let me get the actual number...
<Fallenou>
how can anyone use that for driving something efficiently without too much noise
<lekernel>
ah, it's 22/55. a bit less bad, but still bad
<Fallenou>
is there a trick to detect dynamically the impedance of the I/O and then adapt to it?
<lekernel>
for the input, and 11/52 for the output :-)
<lekernel>
serious chips have an external calibration resistor
<Fallenou>
I know that for instance for our bluetooth modules, we put low quality capa/resistance in the RF stage
<lekernel>
eg. DDR3 memories have a RZQ pin for that
<Fallenou>
and then we have a "production calibration bench"
<lekernel>
and xilinx doesn't have the cost excuse, DDR3 is cheap
<Fallenou>
which calibrates the bluetooth chip writting into registers
<Fallenou>
and then save the best values to the flash nand
<Fallenou>
so each bluetooth module we sell basically have different C/R values for RF stage but it's compensated inside the BT chip
<Fallenou>
by uniq calibration values
<lekernel>
that works against the process variation... but temperature and voltage can also cause changes
<Fallenou>
well, if you have automotives chips, that should not be a problem
<Fallenou>
chips should handle temperature issues in a big range
<Fallenou>
and then if you have regulators .. (automotive ones) then it should be ok
<Fallenou>
it may not be perfect but you should have very less surprises than when using "non automotive AEC-Q100" parts
<lekernel>
SDRAM is DMA-written by the DVI core at all times
<lekernel>
framebuffer is only scanning (and reading the DRAM) when the software says it's on
<lekernel>
and the resolution counter is implemented in gateware and is independent of any potential DRAM write problem
<lekernel>
hmm, or it could be the VGA DAC too
<Fallenou>
yes maybe stop driving the DAC :/
<Fallenou>
to see if there are still SI issues
<lekernel>
let's try the magical S6 OUT_TERM
bhamilton has joined #milkymist
bhamilton has quit [Ping timeout: 264 seconds]
lekernel has quit [Quit: Leaving]
lekernel has joined #milkymist
<wpwrak>
(jtag/serial built-in) yay ! ;-)
Alarm has joined #milkymist
Fallenou_ has joined #milkymist
Fallenou has quit [*.net *.split]
zumbi has joined #milkymist
larsc_ has joined #milkymist
zumbi is now known as Guest64795
21WAAKUO3 has joined #milkymist
Hawk777` has joined #milkymist
juliusb has quit [Write error: Broken pipe]
mumptai has quit [Excess Flood]
mumptai_ has joined #milkymist
Guest37274 has quit [Remote host closed the connection]
larsc has quit [Remote host closed the connection]
Hawk777 has quit [Remote host closed the connection]
larsc_ is now known as larsc
Alarm has quit [Ping timeout: 252 seconds]
<Fallenou_>
larsc: why in switch_to_kernel_mode you do mv r9, r0 before restoring r0 to 0x0 ?
<Fallenou_>
it seems to be doing r9 = r9_set_by_user_space | &lm32_state
<Fallenou_>
why keeping value set by user space (or other kernel code)?
<Fallenou_>
oh no ok got it
<Fallenou_>
it does r0 | r0
<Fallenou_>
sorry
<larsc>
r0 contains the address of the state struct at that point and we need that later in the function as well
<Fallenou_>
I just misunderstood the mv r9, r0 syntax, I thought it was doing r9 = r9 | r0 when it was doing r9 = r0 | r0
<Fallenou_>
just to save &lm32_state in r9 to use it later but be able to restore r0 to 0x0
<Fallenou_>
thanks ^^
Alarm has joined #milkymist
21WAAKUO3 is now known as juliusb
<wpwrak>
(git pull) i think the "clean" approach is to pull the latest upstream, create a new branch on top of that, dump all your changes into the branch, check that it still builds, then run git request-pull on it
<Fallenou_>
I only missed the "git request-pull" part of it :)
Fallenou_ is now known as Fallenou
<wpwrak>
heh :)
balrog has quit [Ping timeout: 264 seconds]
balrog has joined #milkymist
bhamilton has joined #milkymist
<mumptai_>
haha .. "The code quality standard for inclusion of HDL modules is higher than what you may be used to." (milkymist hdl guidelines)
<mumptai_>
:)
bhamilton has quit [Client Quit]
<Fallenou>
where is it?
<lekernel>
fact. raspberry pi model B cannot play 640x360 video with mplayer software decoding and fbdev output (it's even worse with the X overhead)
<Fallenou>
aouch
<Fallenou>
which video codec?
<lekernel>
that oh-so-cool 700MHz ARM is too slow :)
<Fallenou>
if it's some H.264 like codec that can be understood
<lekernel>
or maybe the framebuffer/SDRAM writes are - I'd expect the CPU core itself to be fast enough
<lekernel>
mpeg4
<lekernel>
you need to pay for those license keys to have hardware decoding, lol
<Fallenou>
I guess mpeg-2 would be decoded fine
<lekernel>
another good demonstration that popular != good
azonenberg has joined #milkymist
<lekernel>
it can talk to the M1 through the HDMI board, at least that is good :)
<Fallenou>
at least raspberry is not racist against open source hardware :)
<wpwrak>
(popular != good) if you need something to sink the argument for good: hitler was kinda popular ... ;-)
<lekernel>
hm, so the crosstalk is coming from the SDRAM reads. problems are still there when not driving the VGA DAC (and still disappear when stopping the framebuffer scan)
<lekernel>
Other operating systems include the cost of the various codecs within the price of the operating system. In the case of Linux distributions, free versions of media encoders and decoders are used instead. But hang on – the Raspberry Pi runs a Linux distribution, so why isn’t the MPEG-2 codec free?
<lekernel>
The answer is simple. The Raspberry Pi is designed to be used for education, and while there are many who enjoy its multimedia capabilities, the developers decided to remove MPEG-2 in order to keep costs down. If you want to use MPEG-2, it is there for you to unlock for a small fee
<lekernel>
this is so hilarious
<lekernel>
oh, it gets even better:
<lekernel>
Could I Try a Hacked Codec? [...] The sale of the codec raises money so that the non-profit Raspberry Pi Foundation can work towards its altruistic aims. So don’t go ripping off a codec that costs less than a bottle of beer – pay for it, and help change the world!
<lekernel>
ok, so what else can I use that has a good framerate on the rpi? otherwise I'm sure some people would assume it's the M1 that is slow =]
<Fallenou>
you want to mix output of 2 rpi using the M1 ? :)
<wpwrak>
use a pc ? they come without anyone trying to send you on a guilt trip
<lekernel>
right now I have a eee pc and desktop pc
<lekernel>
and I bought a rpi to replace the desktop for mobile demos, but ...
<Fallenou>
are you sure there is no binary blob somewhere that you can use with your rpi?
<larsc>
well the binary blob is the thing you can buy
<lekernel>
you need license keys that depend on a unique ID written in the chip
<lekernel>
I'm sure most of the license fees go to MPEG LA and payment companies
<lekernel>
what complete BS :)
<Fallenou>
:/
<wpwrak>
you should ask about the split in one of the rpi fanboy forums :)
<Fallenou>
isn't 700 MHz enough to do software decoding of MPEG-2 at , say , 1024x768 ?
<lekernel>
and maybe a bit to broadcom or whoever else wrote those proprietary GPU codecs
<lekernel>
depends how fast your framebuffer is... even moving windows or scrolling text in X is sluggish
<Fallenou>
:/
<Fallenou>
maybe you will eventually have to pay the few $ :/
Alarm has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
Alarm has joined #milkymist
bhamilton has joined #milkymist
lekernel has quit [Quit: Leaving]
kilae has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
bhamilton has quit [Ping timeout: 264 seconds]
froggyto2d is now known as froggyto1d
Alarm has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
bhamilton has joined #milkymist
bhamilton has quit [Ping timeout: 260 seconds]
azonenberg has quit [Remote host closed the connection]
azonenberg has joined #milkymist
playthatbeat has quit [Remote host closed the connection]