<kristianpaul>
adamw_: you got a bios pront i guess
<kristianpaul>
BIOS>
<adamw_>
right. :-o
<kristianpaul>
are you entering in recue mode?
<adamw_>
no
<kristianpaul>
It still happing or just hapen once?
<adamw_>
that's not my goal. he.
<adamw_>
once...only..i'm reflashing image now.
<adamw_>
with  Sch .3
<adamw_>
you don't need to modify your brd, this is just on mysite first.
<kristianpaul>
No boot medium found means that BIOS cant find a "Aplication" to be booted from flash
<adamw_>
i don't want your brd get failure suddently.
<kristianpaul>
wait, you mean it just happen?
<adamw_>
yeah...i just want to know the background of s/w about this message's meaning.
<adamw_>
yeah...from my fast power cycling...(:
<kristianpaul>
well as i said, bios cant find flicernoise from flash
<kristianpaul>
i may be wrong, i'm just doing a quick read of BIOS source code ;-)
<adamw_>
don't try to do this on your site.
<kristianpaul>
what?
<kristianpaul>
ahh power cycling ;)
<kristianpaul>
who knows... :-)
<adamw_>
ok...good..just want someone can read the s/w codes to help me the meanings.:-)
<adamw_>
yeah! Don't do this.
<kristianpaul>
before " No boot medium found" there is a "I: Booting from flash..." message right?
<adamw_>
sure..but it was shown it quite previously.
<kristianpaul>
So if all was okay and it just happen after the power cycling experiment, something get wrong with 0x00920000 memory addr at flash, thats from when flicernoise binary is saved
<kristianpaul>
You should reflash if you want it back
<adamw_>
its previous log is : I: Attempting serial firmware loading
<kristianpaul>
yes, sure
<kristianpaul>
thats for flterm
<adamw_>
then "E: Timeout" -> "E: No boot medium found"
<adamw_>
yes, reflashing.
<kristianpaul>
so flash got corrupted... after power cycling?..
<kristianpaul>
but BIOS still Okay
<adamw_>
after fast power cycling( power on -> off ->on , within 500~600ms)
<adamw_>
like I said , pls don't try to do this on your brd.
<kristianpaul>
OKAY !!
<kristianpaul>
:-)
<adamw_>
yeah..i guess BIOS works well.
<kristianpaul>
Sure, i dont want bother wolfspraul for a board replacement ;-)
<adamw_>
;-)
<kristianpaul>
ahh, will be nice if you could just dump the flash before re-flash, but thats late i think
<kristianpaul>
I imagine it can be usefull at least to check what got corrupted..
<kristianpaul>
Anyway...
<kristianpaul>
adamw_: how long this test took?
<adamw_>
yeah..late, also i don't know how to dump codes inside the flash under "BIOS>"
<lekernel>
but please don't ask me anymore about simple llhdl/cmake problems
<kristianpaul>
:-|
<kristianpaul>
OK
<lekernel>
it's experimental stuff atm and I don't want to spend time on fixing your library issues... there are way more important trouble ahead
<kristianpaul>
mine?
<kristianpaul>
You wrote the code. I jsut telling hey i dint build well on debian. but OK
<kristianpaul>
gotta go, bye
<lekernel>
well, in that case it seems it's rather cmake that doesn't work
<Fallenou>
lekernel: I was more thinking about borrowing one :)
<larsc>
mwalle: how is lm32 uclibc comming along? can you send me your patches?
<lekernel>
kristianpaul: if you have questions about how to implement best that or that llhdl feature into FPGA logic cells, or what's an appropriate abstraction level in the llhdl code for some structure, those are very welcome. but i'm sorry, trivial questions like how to get the program to link against libgmp are inappropriate at the time being
<kristianpaul>
lekernel: (implement FPGA logic cells) actually that will be my next question about, but first i needed at least get hhdl to compile on my side, the question will be about adding spartan-3 support, i know i must read and find _my_self_ the information until seriously bother you ;-)
<lekernel>
if you start supporting different xilinx fpga's, a lot of code can be shared with the current spartan6 support
<lekernel>
it'll probably be a good idea to but that into a semi-generic "libxilinx"
<wolfspraul>
lekernel: hi there. I'm not sure you and Adam understood each other, maybe I'm just the clueless third.
<wolfspraul>
I think what Adam wanted to say is that the board he used to verify the diode fix acted very strange, and is now in a completely (for adam) unclear state.
<wolfspraul>
if I understand this correctly, after about 9-10 cycle tests he first got the CRC error
<lekernel>
hm, maybe the root cause is a DRAM problem
<lekernel>
and hi btw :)
<wolfspraul>
then he reflashed, and it seems to have work again (?), but later on entered the 'unbooted' mode very often, and finally stops working altogether with PROGRAM_B not coming up at all anymore (fig. 16)
<lekernel>
a DRAM issue could cause both the CRC error and failed memory test symptoms
<wolfspraul>
well, the reason I am curiously following this is that we still have those 2 boards that I 'broke' in the initial round of testing
<lekernel>
at the end it does not boot _at all_?
<wolfspraul>
yes, see Fig. 16
<wolfspraul>
last picture
<lekernel>
urgh... imo that board has some other problem
<wolfspraul>
Adam should definitely speak himself, unfortunately he's already out now so we continue tomorrow
<wolfspraul>
nah
<wolfspraul>
we have already permanently damaged 2 other boards, _ONLY_ through power cycle testig
<wolfspraul>
so maybe there are more bugs here, even if the diode fix per se is a good fix
<lekernel>
I don't know. it has never happened to me
<wolfspraul>
also, the fact that he got the crc error and unbooted problems already after 9-10 cycles with the diode fix is strange to me
<lekernel>
and it might be a good idea to find out what is broken on those two boards
<wolfspraul>
sure
<lekernel>
maybe it's just a DRAM solder problem
<wolfspraul>
just not so easy
<wolfspraul>
and the dram solder problem emerges from power cycle testing?
<lekernel>
it can emerge at any time, and according to Murphy's law, during power cycle testing
<wolfspraul>
that will mean PROGRAM_B will not come up anymore?
<lekernel>
no, definitely not
<lekernel>
well, it's not PROGRAM_B btw, but DONE
<lekernel>
that probably indicates a broken/corrupt flash
<wolfspraul>
the reason we are not looking into the old two, fully unbootable (and shelfed) boards right now is that back then we did a lot of testing with a lot of boards
<wolfspraul>
so our actions are not very tracable
<lekernel>
this happened to me once, and went away after reflashing
<wolfspraul>
this time it's much better/much more controlled
<wolfspraul>
so I'm sure Adam will continue to work with this one board that has the diode fix
<wolfspraul>
you think he should just reflash and it will boot again?
<lekernel>
well
<lekernel>
dump the flash first
<lekernel>
so we can see exactly what has been corrupted
<wolfspraul>
sorry yes DONE. so if DONE doesn't come up you can still flash?
<lekernel>
then reflash
<lekernel>
yes, with fjmem
<lekernel>
or the xilinx tool
<lekernel>
DONE does not come up on un-flashed boards btw
<wolfspraul>
does ADam know how to dump the flash on this board? also with xilinx tool I would think?
<lekernel>
I don't know how to do it, but it's definitely technically possible
<lekernel>
maybe impact or urjtag have an option for that, maybe that needs to be coded
<wolfspraul>
that sounds like Adam doesn't know.
<lekernel>
maybe it's as simple as clicking an impact menu
<lekernel>
never did it, I dont know
<wolfspraul>
so power cycling corrupts the flash?
<lekernel>
apparently, this happens sometimes
<wolfspraul>
was the diode fix meant to fix that?
<wolfspraul>
'cannot boot once' is different from 'flash got corrupted for good'
<lekernel>
the diode was meant to fix both problems
<kristianpaul>
urjtag have the readmem command, you just specify address, lenght and filename
<lekernel>
at least from my understanding of them
<wolfspraul>
lekernel: do you have any theory what may leave a written corruption in the flash chip?
<lekernel>
so first, take that non booting board and read back the flash so we can test the "corrupted data" theory
<lekernel>
yes, I explained it already
<lekernel>
during power up, there might be an invalid signal on the write enable pin
<lekernel>
which could cause write commands to be issued that would corrupt the flash's contents
<lekernel>
the diode was supposed to fix this by asserting the flash reset low (and disabling it) until other signal levels are stable
<roh>
morning
<wolfspraul>
ok
<wolfspraul>
roh: good morning!
<lekernel>
good afternoon :)
<wolfspraul>
btw, I didn't realize that the 'dhl package' we sent was actually a regular mail package
<wolfspraul>
oh well
<wolfspraul>
so we are at the mercy of Taiwan Post now to deliver it
<lekernel>
in germany, dhl = regular mail, no?
<roh>
lekernel: ack.
<roh>
dhl is what german post was before
<lekernel>
it's a bit messy, I sometimes get 2 or 3 different postmen every day
<wolfspraul>
the good news is that tracking says it's in Taiwan already
<wolfspraul>
it's moving
<wolfspraul>
lekernel: ok it sounds like more work for Adam.
<lekernel>
between PIN AG, DHL, German post, ... :)
<roh>
lekernel: only 3?
<lekernel>
wolfspraul: I thought I explained that to him already
<roh>
there is also gls, dpd, fedex, ups and some more (only packages) .. for letters there are only a few besides the 'post'
<lekernel>
but if the diode+reset IC make no improvement, it's probably another problem :(
<wolfspraul>
lekernel: you mean you explained the 'invalid signal on write pin'?
<lekernel>
yes
<wolfspraul>
if you did then I'm sure that's clear. I am just following.
<wolfspraul>
yes, there may be another problem
<wolfspraul>
'no improvement' may be too hash
<wolfspraul>
harsh
<wolfspraul>
let's see what Adam says about the latest status
<lekernel>
the invalid signal on write pin could also cause intermittent no-boot, because even if no data write happens, the flash goes to another mode than "read array" when it receives a command
<lekernel>
and the fpga would receive flash status information instead of bitstream, DONE would not go high, and the board would not boot
<wolfspraul>
if we know that the diode fix itself makes the board meet stated IC requirements, and is proven to work and cause no side-effects, then that's a good thing in itself
<lekernel>
btw all DONE means is "fpga has successfuly read a bitstream"
<wolfspraul>
I mean "diode+reset ic"
<wolfspraul>
do you see anything right now that would make you want to not add the diode+reset ic fix?
<lekernel>
no, I don't
<wolfspraul>
ok, good
<roh>
wolfspraul: yay (package)
<roh>
wolfspraul: what would have been 'not regular mail' ?
<wolfspraul>
roh: DHL doesn't offer that to Taiwan
<wolfspraul>
I mean the 'other' DHL
<wolfspraul>
it's confusing.
<roh>
?
<roh>
i still hope the taiwanese people can ready my address sticker and my handwriting
<roh>
was difficult to squash the address into the 3 lines
<lekernel>
argh, a BGA socket for the spartan6 is $566