<lekernel>
mh, how do you relocate the "Hello world!" string then?
<mwalle>
there are no relocations
<mwalle>
static binaries yet
<lekernel>
it's in a read-only section?
<mwalle>
    140:      78 01 00 00    mvhi r1,0x0
<mwalle>
    144:      38 21 19 50    ori r1,r1,0x1950
<mwalle>
    148:      f8 00 00 06    calli 160 <puts>
<mwalle>
  3 .rodata      00000044  00001950  00001950  00002950  2**2
<mwalle>
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
<lekernel>
puts? so there's a libc...
<mwalle>
ahh, i meant theres no official libc
<mwalle>
yes im using uclibc
<mwalle>
but not theobromas one
<kristianpaul>
what is splash.mcs ?
<kristianpaul>
userfs.mcs = flickrnoise?
<lekernel>
forget about those outdated files
<lekernel>
there's no more userfs.mcs
<kristianpaul>
argg
<lekernel>
splash.mcs = boot splash screen
<lekernel>
I recommend you use msd-dec2010 for flashing your board
<kristianpaul>
so i just send the file _as_it_is_
<kristianpaul>
?
<lekernel>
yeah, the msd archive contains raw binary images
<lekernel>
mind that the bitstream is bit reversed, as discussed yesterday on irc
<kristianpaul>
yes yes
<kristianpaul>
good all is loged now
<kristianpaul>
patent litigation..
<kristianpaul>
reverser eng for competitive products, lol
<kristianpaul>
oops sorry
<kristianpaul>
(flash with ftdi_eeprom in linux) no will not, i dont have how to boostrap my jtag-serial board in the case something go wrong..
<lekernel>
short pins 1-5 of eeprom, connect to usb, remove the short, reflash
<lekernel>
simple
<lekernel>
i do that with tweezers
<kristianpaul>
lekernel: do you already reflashe on linux with no problem?
<kristianpaul>
any way i dont see what do that
<lekernel>
no, I didn't try
<kristianpaul>
me either, lets adam or soembody with more than one pod do it first :-)
<kristianpaul>
btw how do you built soc-1.0RC2.fpg?
<lekernel>
oh, you shouldn't break it... worst case you have to plug it with the eeprom shorted
<kristianpaul>
and why bios is bin and flickernoise  fbi..
<lekernel>
bitgen -g Binary + bit reversal
<kristianpaul>
ergg i will not brick my pod no, that not
<kristianpaul>
k
<lekernel>
because the bios has to know how many bytes to load into sdram, so it has a "fbi" header with that (and a crc)
<lekernel>
the bios itself is executed in place and therefore does not need such a header
<kristianpaul>
ok let me see if i recover my booting at least bios for now,
<mwalle>
mh nios call instruction is a little bit fucked up.. call has a 26bit immediate the resulting pc is {pc[31:28], imm26, {0,0}}
<kristianpaul>
i need to work later in a reduced version of rtems (not that i dint enjoy flickernoise) just i dont need all that audio/png/and other stuff for what i want from MM1 now
<lekernel>
what do you want from mm1 now? :)
<kristianpaul>
:D
<kristianpaul>
Implement a GPS baseband processor in your SoC
<kristianpaul>
check namuru project, is a posible starting point for some correlation stuff, if it works i can re-use mico32 may be add new instructions... well i dont know thats for later
<kristianpaul>
larsc: can you upload your last *.bin files to somwhere i need compare something..
<kristianpaul>
argg i still not getting boot :/
<lekernel>
you can configure the fpga manually with "pld load"...
<kristianpaul>
sure
<lekernel>
then if you have a bios image, it should at least do something
<kristianpaul>
he well pld load is ok if you are sure your bios is on the flash
<kristianpaul>
also i dont want pld load always :-|
<lekernel>
it'll help you with figuring out what is wrong with the flash
<lekernel>
btw pld load expects a .bit file (i.e. with Xilinx header), it'd be nice to have .fpg file support (raw bitreversed bitstream) as well...
<kristianpaul>
i myst confess i erased it first
<kristianpaul>
hmm thats true
<kristianpaul>
eraseflash i mean :-)
<lekernel>
you erased the complete flash chip?
<kristianpaul>
it seems
<lekernel>
then you need to reflash the standby bitstream as well
<lekernel>
and perhaps rescue partitions
<kristianpaul>
standby bitstream > thats what power up the fpga?
<lekernel>
yes
<kristianpaul>
ah, i see then
<kristianpaul>
do you have somwhere a memory map of flash?
<lekernel>
not graphically, but just look at flash.h
<kristianpaul>
k
<kristianpaul>
make: /tools/byteswap: No se encontr el programa
<kristianpaul>
ok i miss that
<larsc>
you'll have to set MMDIR to your milkymist dir
<kristianpaul>
oh why this take so long...
<kristianpaul>
i wast that way before or is because i swiched to last ISE..
<lekernel>
kristianpaul: it's always been like that. if you dislike ise, feel free to contribute to llhdl :)
<kristianpaul>
I need a faster computer then ;-)
<kristianpaul>
time relativity is hard when you need something NOW, just that :-)
<kristianpaul>
infrared and nanonote is other interesting aprouch for comunication, now that LED can achieve wireless data tramission too
<larsc>
lekernel: is navre/softuse fully ohci compliant?
<lekernel>
no, it's not ohci compliant at all.. ohci is a major PITA and the current avr firmware only implements input device support with a special protocol
<lekernel>
I wanted to have OHCI in the beginning, but the benefit/pain ratio turned out to be way too low
<larsc>
ok
<kristianpaul>
larsc: is it mandatory write again in flash  rescue*
<kristianpaul>
lekernel: ^
<kristianpaul>
i just worried about mac address
<wolfspraul>
that would be my least concern :-)
<wolfspraul>
just get it to boot first, who cares about mac address?
<wolfspraul>
you only have 1 m1 there anyway, won't disturb anybody...
<kristianpaul>
no no i dont care about mac it self
<kristianpaul>
just missing this data will not bios to boot *may* *be*
<wolfspraul>
I highly doubt that, but let's see.
<kristianpaul>
k
<wolfspraul>
it's just a unique id, that's all
<wolfspraul>
it will boot no matter what the unique id is
<lekernel>
kristianpaul: do you really think i'd have coded something to totally prevent booting if the mac address isn't set...?
<kristianpaul>
yeah sure,
<kristianpaul>
ok ok, no more dumb questions
<kristianpaul>
hides
<kristianpaul>
flashmem 0 bitstream.bin noverify
<kristianpaul>
wiki said that^
<kristianpaul>
but flash.h points REGULAR BITSTREAMÂ Â (0x006E0000)
<kristianpaul>
what i missing to understand this..
<mwalle>
wiki is wrong
<mwalle>
mh, not exactly, the bitstream may be the standby one :)
<kristianpaul>
yeah
<kristianpaul>
let try again i follow flash.h and still not automatic boot..
<kristianpaul>
not exactly <-- what about: flashmem 0x180000 bios.bin noverify != REGULAR BIOSÂ Â Â Â Â Â (0x00860000)
<mwalle>
ok the wiki is wrong/old :)
<kristianpaul>
argg but i still cannot boot automcatically :/
<lekernel>
from your description, it seems urjtag writes the flash in little-endian for some reason...
<kristianpaul>
I just compiled urjtag from upstream yday, as it seems to not been in fedora
<kristianpaul>
my locally compiled bios.bin begin with 98 00 00 00
<lekernel>
good
<lekernel>
now, the flash should also have 0x9800 at address 0 and 0x0000 at address 1
<lekernel>
modify the urjtag code to get that to work and please send a patch
<larsc>
i wonder why my bios is byteswapped
<kristianpaul>
me too
<kristianpaul>
jtag> endian
<kristianpaul>
Endianess for external files: little
<lekernel>
ah, ok
<kristianpaul>
initbus fjmem opcode=000010
<kristianpaul>
frequency 6000000
<kristianpaul>
detectflash 0
<kristianpaul>
oops
<kristianpaul>
problem solved :-D
<kristianpaul>
hey,  larsc is fast editing wiki  :-)
<kristianpaul>
wee
<kristianpaul>
the noise is back ;-)
<kristianpaul>
now document all this
<kristianpaul>
phew
<kristianpaul>
is okay if i remove ALL mcs related isntruction from the  flashing page?
<kristianpaul>
or should i create a new title there?
<lekernel>
I think you can remove the mcs instructions
<lekernel>
only the xilinx tools are using them, and we're moving away from them
<kristianpaul>
yay !
<kristianpaul>
is DHCP working?
<lekernel>
in flickernoise yes
<kristianpaul>
i'm getting  a BOOTP call failed conection timed out..
<kristianpaul>
i'll re check all
<lekernel>
will soon introduce LZMA-compressed flickernoise images. this promises a lot of fun ;)
<lekernel>
where/what is that?
<kristianpaul>
i'm just reading from rtems serial terminal from the MM1
<kristianpaul>
after enable DHCP on flkrnoise
<lekernel>
this means you don't get a dhcp reply
<lekernel>
maybe it would have been a good idea to check with wireshark before...
<kristianpaul>
it should
<kristianpaul>
i'll try static ip
<kristianpaul>
damn there is no ping???!!
<kristianpaul>
:-|
<lekernel>
works for me and on dozens of other boards...
<kristianpaul>
yeah sure..
<lekernel>
are your ethernet leds on?
<kristianpaul>
of course
<kristianpaul>
if i ping the board i got activity from the orange one
<lekernel>
try without a switch, direct connection to pc...
<kristianpaul>
hmm
<lekernel>
and use wireshark
<kristianpaul>
ok
<lekernel>
that being said, the ethernet driver has tons of bugs that Fallenou never fixed...
<kristianpaul>
seriouslly there is NO way of ping command in rtems?
<mwalle>
imcp, or was that umon ?
<mwalle>
icmp
<lekernel>
i don't know... rtems has the bsd stack though, so it should be fairly complete
<lekernel>
but the shell might not
<kristianpaul>
oh dear, no binutils no ping, no netcat, :-|
<lekernel>
those are useless on a VJ station
<kristianpaul>
and rtems?
<kristianpaul>
anyway
<kristianpaul>
i'll starting more about rtems
<lekernel>
and if you do need ping or netcat, it's shouldn't be a big deal to write them, if no one did it before
<kristianpaul>
there is NFS support?
<lekernel>
yes
<kristianpaul>
grins
<lekernel>
but it's sometimes instable... if I ever participate in GSoC again i'll have a totalitarian policy about testing and bugs
<larsc>
hm, interressting. i have a 32bit constant. and instead of doing something like, mvhi r1, 0x1234; ori r1, r1, 0x5678 gcc puts it somewhere in the data section and does mvhi r1, hi(addr); ori r1, lo(addr); ldw r1, (r1+0)
<larsc>
and mm_segment_t is typedef union { unsigned long seg; } mm_segemnt_t;
<kristianpaul>
lekernel: is okay if you upload to mm.org/somethng, the files fjmem.bit splash.raw standby.fpg, of course i'll document how get it but is easy have it around for a hurry
<lekernel>
yeah...
<kristianpaul>
wait i'll pass the tarrball link then
<lekernel>
or just put them on your website
<lekernel>
and link from the wiki
<kristianpaul>
ah sure
<lekernel>
maybe even simpler
<kristianpaul>
i'll do that way then
<lekernel>
i'll make proper binary releases later
<kristianpaul>
ah, sure
<lekernel>
i.e. for the next board batch :)
<lekernel>
for standby.fpg: you used bit reverse, right?
<kristianpaul>
any one can recommend a commad line tool for generating html index of a directory?
<lekernel>
and put urjtag in big endian mode?
<kristianpaul>
yes
<lekernel>
ok, good
<lekernel>
now we have that flashing part straight :)
<kristianpaul>
a makefile will just take of that :-)
<lekernel>
sometimes nice to have would be the ability to load *.fpg files with "pld load"... i'll have a look at this if no one does before
<kristianpaul>
thats a good feature
<kristianpaul>
lekernel: can you tell us a bit more about rescue mode workflow?
<lekernel>
it's simple, the standby bitstream loads the backup bitstream, which in turns loads the backup bios which tries to boot the backup boot image...
<kristianpaul>
how i do enter in rescue?
<lekernel>
press PB1 when pressing PB2 to power the board
<kristianpaul>
if i intetionally corrupt regular bios/bittstream it will jump to rescue as well?
<kristianpaul>
k
<lekernel>
no, rescue mode is only entered manually
<kristianpaul>
i see
<larsc>
lekernel: if I make the constant small enought to fit into 16bit it's loaded directly.
<lekernel>
weird...
<lekernel>
maybe you can try to e-mail Jon Beniston about that. he wrote the original lm32 support patch
<lekernel>
you're using a vanilla elf compiler, right? no fdpic or anything?
<larsc>
i tried to reproduce it in a standalone binary and it dodn't work
<kristianpaul>
ah bad luck with the LG remote control
<lekernel>
where does that happen?
<larsc>
i'm building the kernel
<lekernel>
what compiler are you using?
<larsc>
gcc 4.5.2 from rtmes
<lekernel>
the problem should already present in the unlinked .o file, so by running the exact same command and narrowing down code + compiler flags you should be able to reproduce it in a standalone piece of code I think
<lekernel>
no?
<lekernel>
ok, so no fdpic or other crazy things a priori
<larsc>
ah it's -Os
<lekernel>
yup. generating 4 words instead of 2 sure optimizes for size :)
<lekernel>
argh...
<lekernel>
and not using -Os crashes GCC, right? :)
<lekernel>
yeah, mail Jon Beniston and cross your fingers
<mwalle>
maybe tomorrow we have bFLT support :)
<lekernel>
no need to file a bug in the gcc database, the current maintainer doesn't look at them, and the other fsf people only care about fighting microsoft
<mwalle>
at least for non shared, non PIC binaries
<larsc>
mwalle: :)
<mwalle>
gn8 :)
<kristianpaul>
nite
<kristianpaul>
lekernel: byteswap and bitgen for the standby.fpg