<aw> xiangfu, do you know what it wants to do after showed up 'Bitstream length: 1484404' while flashing m1?
<xiangfu> aw, let me check.
<xiangfu> aw, from the reflash script file:pld load ${FJMEM}
<xiangfu> initbus fjmem opcode=000010
<xiangfu> frequency 6000000
<xiangfu> Bitstream length: 1484404 means load fjmem done.
<xiangfu> next should be 'frequency 6000000'
<xiangfu> should be output "Setting TCK frequency to 6000000 Hz"
<aw> so 1484404 is done means load fjmem finished? so then what's the next step script trys to do? will 'frequency 6000000' mean UrJtag starting to set somethings into fpga?
<xiangfu> sorry. next should be "initbus fjmem opcode=000010"
<aw> what does this meaning? fpga trys to do somethings you guess?
<xiangfu> aw, I would advice change on Jtag board. try reflash again.
<xiangfu> using another jtag board, try reflash again.
<xiangfu> initbus mean try to initializes the external memory bus, then we can access the flash chip
<xiangfu> aw, each m1 you using different jtag board, right? then we can try to using one working jtag board on this m1. to detec if it's jtag board problem.
<aw> xiangfu, yes, each m1 with its won jtag board. mmm...good idea
<kristianpaul> also i wondered the dmesg output after connect that board, but yes better try another
<aw> xiangfu, your this idea makes me happy now. ;-)
<kristianpaul> :)
<aw> although I don't change another jtag board to 0x32, but now it's flashing... I just tried to plug out and replug again though. ;-)
<aw> ox32: hmm...d2/d3 dimly lit after flashed. with BEN shorter cable. :(
<aw> let's change a new jtag board.
<aw> after changed to other jtag rc1 board...still stops at 'Bitstream length: 1484404'
<kristianpaul> hum, but jtag serial cabled passed testing all okay it seems, so dunno if can be a jtag-serial board  issue
<wolfspraul> sounds like the problem is with the flash chip?
<xiangfu> maybe
<aw> used a new jtag rc2 still stops at there.
<aw> okay, so you guys think it's probably a flash chip problem related?
<aw> not bad. at least narrow the area to find possible cause.
<aw> tks
<wolfspraul> well
<wolfspraul> we are guessing
<wolfspraul> but at least 0x32 never successfully flashed and booted before
<wolfspraul> unlike for example 0x34
<wolfspraul> so for 0x32, yeah, maybe it's just a flash soldering problem?
<aw> yes, never successfully flashed, but at least today became only was flashing... once
<wolfspraul> yes, but then it didn't boot (configure)
<kristianpaul> yeah, probably flash something around or flash chip it self
<aw> possible . I'll see it. just asked here to know more steps about scripts. ;-)
<kristianpaul> but from the pastebin looks like jtag lost connection with fjmem...
<kristianpaul> xiangfu: hi,
<xiangfu> kristianpaul, hi
<kristianpaul> xiangfu: you did some dd from /dev/zero to the first blocks of the 512Mb flash you sent me, to make it recognice by mm bios?
<kristianpaul> or formated? (mkfs.fvat)
<kristianpaul> i made the mistake of format the card now it is recogniced but i hit a bug with the fat library implemented in bios...
<kristianpaul> in wich it dint recognice files on the memory..
<xiangfu> kristianpaul, ? I lost. what file I sent to you?
<kristianpaul> card
<kristianpaul> 512mb and 1Gb remenber
<kristianpaul> ?
<xiangfu> oh. memcard. 512MB.
<kristianpaul> sorry my english is not very good today..
<kristianpaul> yeah
<xiangfu> the BIOS only know fat16.
<kristianpaul> it was working well, actually i  put boot.bin cmdline.txt and initrd.bin on it
<kristianpaul> yeah, but happen that i formated the card, in fat16, but the error is not about fat32 not supported.
<kristianpaul> ahh ;)
<xiangfu> which is used on RC3 memcards.
<kristianpaul> but those are brand new cards isnt=
<kristianpaul> ?
<kristianpaul> cause the 1Gb you sent me was almost all zero, expect the 512Mb that seems to have a remaning metadata, but anyway
<kristianpaul> the point is you already gave me a good link to see :)
<kristianpaul> mkdosfs """"
<kristianpaul> ahhh
<kristianpaul> i see now
<kristianpaul> thanks xiangfu
<xiangfu> nope. :)
<kristianpaul> hum this is script is new, i see
<kristianpaul> ha very hackisght the tr :)
<kristianpaul> but kind of you and lekernel ;)
<kristianpaul> i can try linux again this weekend
<kristianpaul> ok..
<xiangfu> kristianpaul, which linux image you using?
<kristianpaul> oh, ok
<kristianpaul> i'll go for some tea and try :)
<kristianpaul> from commit 5a05105aee18d4abb6cd8597c4e0db254b1dde46
<xiangfu> can we build the 'initrd.bin' inside the 'boot.bin'?
<xiangfu> lars said we don't need cmdline.txt anymore. if we build 'initrd.bin' inside the 'boot.bin' then we only needs one file
<xiangfu> also we need change the 'openwrt-lm32-root.ext4' to 4M
<kristianpaul> i like this openwrt-milkymit, is so small :)
<kristianpaul> may be i can try to package osgps ;)
<xiangfu> yes. I have enable the all package as modules when build openwrt-milkymist. but it's not working now. maybe miss something.
<kristianpaul> so it can void ipkg stuff and build the package directly to rootfs?
<xiangfu> that needs IMAGE BUILDER in openwrt. I only tried once. it not works well.
<xiangfu> it's like you already build all packages. but want select 10 or 20 of them in rootfs, then using IMAGE BUILDER. that can fast build rootfs.
<xiangfu> it's just unpack the package then create a rootfs. no compile I remember.
<kristianpaul> still formating, i guess take a while?..
<xiangfu> no. should be very fast. make the "DEV=sdb" correct
<xiangfu> dont' format your harddisk.
<xiangfu> make the sure the 'DEV=sdb' is your memcard
<xiangfu> in your computer
<kristianpaul> sure, i fixed DEV
<kristianpaul> cause sdb is a _important_ parition on my computer ;)
<xiangfu> yes. :)
<kristianpaul> actually get stucj in fdisk
<kristianpaul> 13971 pts/35   R+     0:15 fdisk -b 512 /dev/sdc
<kristianpaul> hum that FDISK_CMD_FILE..
<kristianpaul> follwing manually the fdisk automation but something not right
<xiangfu> hmm..
<kristianpaul> ignore, if work for you okay, now i should find the way to make it work in my system :)
<kristianpaul> but imho expect command is a better way to automate input to others commands
<xiangfu> sorry. what you mean?
<kristianpaul> but a bit complex tought.. https://secure.wikimedia.org/wikipedia/en/wiki/Expect
<xiangfu> kristianpaul, oh. command 'expect' , I got it.
<xiangfu> will try that next time.
<aw> 0x72: actually is both Y1 Xtal no signal and L1's pad not soldering well. Replaced a Y1 then audio codec circuit work well. ;-)
<wolfspraul> nice. another one fixed :-)
<Alarm> I have installed and unpacked Xilinx_ISE_DS_Lin_13.2_O.61xd.0.0. Is there a command to run?
<Alarm> to complete the installation?
<larsc> unpacking should be enough
<kristianpaul> Alarm: source /opt/Xilinx/13.2/ISE_DS/settings32.sh
<kristianpaul> Alarm: or whatver you install dir
<kristianpaul> you can run "ise" command to make sure
<kristianpaul> but dont bother to run that thign as from milkymist/boards/milkymist-one/flas a make will be enought i think
<GitHub117> [extras-m1] yizhangsh pushed 3 new commits to master: https://github.com/milkymist/extras-m1/compare/751a2ff...236db47
<GitHub117> [extras-m1/master] added bleeds, adjust M1 logo color - Yi Zhang
<GitHub117> [extras-m1/master] Merge branch 'master' of https://github.com/milkymist/extras-m1 - Yi Zhang
<GitHub117> [extras-m1/master] adjust color to colse to Pantone 2935 C - Yi Zhang
<Alarm> I installed the Webpack ise in paltest but make does not work because missing xst
<kristianpaul> Alarm: do you ran source command ober the right settings.sh file?
<kristianpaul> also can you please use pastebin.com or such so we can see clearly error you got?
<Alarm> kristianpaul: http://pastebin.com/YLZWBmT2
<kristianpaul> Alarm: where did you installed Xilinx ISE?
<kristianpaul> full dir please
<kristianpaul> source /opt/Xilinx/13.2/ISE_DS/settings32.sh
<kristianpaul> is the command in my system i ran in order to set right env variables for xst to run
<kristianpaul> so you should run something similar in your system,
<Alarm> kristianpaul: /opt/Xilinx/13.2/ISE_DS/
<kristianpaul> same
<kristianpaul> run that then
<kristianpaul> not of my fully care, but you should try to avoid xst as run, we never know what we can get from it ;)
<kristianpaul> but ignore my last comment for now :)
<kristianpaul> run xst as root i mean, sorry
<GitHub141> [linux-milkymist] mwalle pushed 1 new commit to master: http://bit.ly/plnR5A
<GitHub141> [linux-milkymist/master] lm32: unify asm-offsets.[ch] - Michael Walle