<kristianpaul>
Fallenou: console.c is very related to his name i dunno if it can help me
<Fallenou>
oh and thanks for the synthesis log kristianpaul I will have a look
<kristianpaul>
it i want cat to /dev/console1 ..
<kristianpaul>
s/it/if
<kristianpaul>
ok Fallenou
<Fallenou>
I don't understand
<kristianpaul>
i want my driver be /dev/console1
<Fallenou>
then just modify the line in console.c :)
<Fallenou>
that gives the name
<kristianpaul>
sure
<kristianpaul>
but
<kristianpaul>
not sure if the functionallity i want
<kristianpaul>
i need read more
<Fallenou>
I think it's what you want
<Fallenou>
just modify line 165 of console.c
<kristianpaul>
thats already done
<kristianpaul>
ok
<kristianpaul>
i'll try as it is right now
<Fallenou>
yes don't ask youself too much question before even trying ;)
<kristianpaul>
heh
<kristianpaul>
bad habit
<Fallenou>
try it, and ask yourself if it does not work :p
<kristianpaul>
lol
<Fallenou>
actually it's good to think before trying, but not to think too much sometimes :p
<kristianpaul>
more logical and productive way indeed
<Fallenou>
you try, it fails you think you try again it fails etc
<Fallenou>
i'm off ! :)
<Fallenou>
good luck
<kristianpaul>
nice sleep
<kristianpaul>
n8
<Fallenou>
thanks
<kristianpaul>
aw_: very interesting your mail  about DV7125 and ground pins
<aw_>
kristianpaul, yes, me too
<kristianpaul>
If wonder if you are going to test with lekernel help the "just ground the video output signals" theory.
<aw_>
I'll try to grep milkymist sources. surely I will.
<aw_>
the way is that trying to let no high active frequency comes from fpga.  i think that currently we are not very sure that if those parallel digital signal will influence audio quality.
<aw_>
so if stop digital video sources then can monitor if playing GUI the loud noise will be taken less. :-)
<aw_>
but i don't know every piece of higher s/w even driver needs to modify somewhere or just like 'pull down' all video out sources.
<aw_>
kristianpaul, thanks that you did the SoC Diagram. :-)
<kristianpaul>
Acording to lekernel reply on the ML it is just the HDL/Verilog part wich need to be modified, well i'm aware of way of disable modules of Milkymist wich is using the ENABLE_VIDEOIN variable, may be xianfgu can give, actually i asked that on the ML but not get a clear answers if this the easy way to test from last lekernel reply
<kristianpaul>
aw_: ah well it was already made by sebaestien, i just updated it a bit..
<aw_>
kristianpaul, addresses are that you added?
<kristianpaul>
aw_: yes i added
<aw_>
kristianpaul, ;-)
<kristianpaul>
also some bus clarification from *my* consideration
<kristianpaul>
some extra labels and removed old modules..
<kristianpaul>
clean up :-)
<aw_>
ah..great.
<aw_>
kristianpaul, I was thought that to let 'VGA_PSAVE_N' pin low to power down ADV7125. But he tried to pull all R/G/B sources low which is better idea than mine to totally simulate no high frequency.
<aw_>
kristianpaul, the AC97 wires and RGB routes they are close together came from fgpa area even there's one inner gnd layer between both. so do this experiment i think we can know if video sources influences audio. ;-)
<kristianpaul>
back
<kristianpaul>
sorry was at dinner
<kristianpaul>
wtf happened with tmplab :(
<roh>
hm?
<kristianpaul>
it is a shop now?
<kristianpaul>
irc channel is dead?
<kristianpaul>
ah, well new webpage is not a shop but wow is looks like
<kristianpaul>
or is me that thinks every where i saw an arduino + wires + motors is because sellling
<lekernel>
aw_: hi
<aw_>
lekernel, good morning
<aw_>
copied milkymist sources already
<lekernel>
ok, do you have ise 13.1
<lekernel>
?
<aw_>
mine is 12.3 not 13.1
<aw_>
is it okay?
<xiangfu>
me too. I have the 12.3. is the version very important?
<xiangfu>
I am downloading the 13.1 now
<aw_>
so we need 13.1?
<lekernel>
yes
<lekernel>
12.x doesn't meet timing and is very slow
<aw_>
okay..second...it may quite long time...
<lekernel>
ah, and have you installed urjtag already?
<aw_>
yes, i had installed urjtag.
<xiangfu>
download 13.1, need ~5h
<aw_>
i am downloading..not sure how long it will take on mine.
<aw_>
lekernel, i think that it will take 3 ~ 4 hours to finish download. i got 10% only.
<aw_>
do i have others needed to install or download?
<lekernel>
you may want to check that urjtag works and you can load (not flash) a bitstream with it
<aw_>
do you mean 'pld load' and such 'jtag -n batchfile'?
<aw_>
if yes, i think that i can, just don't know how to build *. bin, *fbi, *.fpg.
<kristianpaul>
Fallenou: /opt/rtems-4.11/lm32-rtems4.11/milkymist//lib/include/rtems/confdefs.h:886:7: error: UART1_DRIVER_TABLE_ENTRY no se declaró aquà (no en una función)
<kristianpaul>
ha, this was not copied to the build folder
<lekernel>
aw: how is it going?
<Fallenou>
kristianpaul: try putting the driver table entry in the .h of the driver
<Fallenou>
like it's done for the milkymist_gpio driver
<kristianpaul>
Fallenou: i already did
<kristianpaul>
wait a mi
<kristianpaul>
n
<Fallenou>
then don't forget to add the header :)
<Fallenou>
in Makefile.am
<kristianpaul>
ahh!
<Fallenou>
"include_bsp_HEADERS"
<aw>
lekernel, just flashed soc-1.0RC2.fpg, bios-1.0RC2.bin, flickernoise-0.2.fbi
<kristianpaul>
forget fullness
<kristianpaul>
second
<lekernel>
aw: you didn't need to, but good.
<aw>
but ISE download is very slow though..
<lekernel>
no surprise here :)
<aw>
so i think that tomorrow I'll follow you to modify source then build bitstream file...seems I can not done this tonight.
<aw>
60% done only
<lekernel>
ok
<lekernel>
any news on the other rc3 board improvements?
<lekernel>
did you test and select a fuse to protect against overvoltage?
<lekernel>
and zener?
<aw>
those final two are not yet though..
<lekernel>
also I should be receiving the wolfson audio codec samples tomorrow
<aw>
during sourcing bat I'll order fuse again.
<lekernel>
aw: just order samples of fuse, right?
<lekernel>
we need to test it before production
<aw>
no..the rest parts for rc3 batch I'll order all except fuse and zener I need to fine tune again..
<aw>
surely test them before rc3. just meanwhile ordering the rest.
<aw>
also I've not decided the parts for video input protection.
<lekernel>
I'd say just use 4 diodes... there are dual diodes in SOT-23, so you'd need only 2 extra packages per video channel
<aw>
there's 'Due to the analog nature of the video signals, uni-polar TVS diode arrays are not recommended as the may clip the negative part of the video signal. ' mentioned
<lekernel>
normal diode
<lekernel>
sure, but with two normal diodes in series, it'd only clip at about -1.4V
<aw>
so i was wrong on using TVS thoughts.
<lekernel>
which a normal video signal isn't supposed to reach afaik
<aw>
even used normal diodes, you got correctly.
<aw>
so the bias for supplies I'd like to use our +3.3V bias to clamp. how do you think?
<lekernel>
or yeah use those littelfuse components
<aw>
right. so the littlefuse is still good for us. I just want to know that we add with good reasons and surveys more. :-)
<lekernel>
maybe just take the littelfuse thingy
<lekernel>
it's made for that :)
<aw>
surely I can directly use the littlefuse proposed.
<lekernel>
less problems
<lekernel>
yup. i'm for the littelfuse integrated protection
<lekernel>
let's keep things simple
<aw>
um...that one is also for IEC 61000-4-2 standard though. :-)
<aw>
well..sounds you'd like this although i surveyed another...well..we done this, just pick this. :-)
<lekernel>
yup. just order some littelfuse samples and test them
<lekernel>
so you need to sample: 1. littelfuse protections 2. input fuse 3. ~5V zener
<lekernel>
keep me tuned about those
<lekernel>
meanwhile i'll try the other audio codec i'll receive tomorrow
<aw>
yes, I'll fine test them again.
<lekernel>
bbl
<aw>
good
<aw>
yup..I'll keep downloading...but offline irc.  bbl
<kristianpaul>
argg same error
<kristianpaul>
and i already ran automake also after modify Makefil.a
<kristianpaul>
m
<Fallenou>
did you run the bootstrap ? (don't know fi it's necessary but maybe ...)
<kristianpaul>
yeap...
<kristianpaul>
with -c then -p the no parameters
<kristianpaul>
i also erased all in the build dir and confgiure... again
<kristianpaul>
damn what stupid typo did i this time..
<lekernel>
pff, farnell asking me to complete a form on dead trees about my company status so I could place orders... the joys of germany...
<lekernel>
not to mention that my German credit card wouldn't work in their system (I wonder why I took one, really) and that I had to use my french mastercard
<lekernel>
stupid
<Fallenou>
lol
<lekernel>
and it's a 25 euro order. i'm sure the salaries of the people they paid to bother me with those stupid inquiries already offsets their markup by a pretty wide margin
<kristianpaul>
Fallenou: zarlink website have more accutate informacion
<Fallenou>
hum ok
<kristianpaul>
correlator basically from my understanding allo to track the PRN codes in the raw data coming from the RF front end
<Fallenou>
it's digital analysis, right ?
<kristianpaul>
also it should allow anticipate changes in the signal so you can track it no matter if you're movin or the satellite (actually this always moves)
<kristianpaul>
there is also some DSP-like stuff on the software side
<kristianpaul>
there are some algorythm about that,
<Fallenou>
seems nice
<kristianpaul>
i dint dig on that part yet
<kristianpaul>
_but_ one of the obstacles for GPS signaling is that you should adapt to different enviroments
<Fallenou>
would it be possible to implement a correlator on fpga?
<kristianpaul>
it is already
<kristianpaul>
namuru project is about that
<Fallenou>
oh :)
<kristianpaul>
it is proven to work with a zarlink frontend and a niosII/Altera SoC
<Fallenou>
very nice !
<kristianpaul>
now i hope with a SiGE front end and the Milkymsit SoC ;-)
<kristianpaul>
i have some dubts with clock but i think if the verilog code is not using some special altera libraries it can be migrated
<kristianpaul>
but all i said is bullshit for now :-)
<Fallenou>
just try
<Fallenou>
and you will know
<Fallenou>
if it works ;)
<kristianpaul>
yeah
<kristianpaul>
i'm following you recomendations _really_