sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<whitequark>
hey sb0
<whitequark>
what does ranlib do
<whitequark>
why do you run it
mumptai has joined #m-labs
<cr1901_modern>
Are you using a Linux system?
<whitequark>
yea
<whitequark>
well, the target is bare-meta
<cr1901_modern>
My guess is that ranlib operates on archives. Static libs on Linux are, essentially, a huge lie, and so ranlib is a noop so that makefiles that depend on it existing don't bitch.
<whitequark>
I'm not interested in guesses
<whitequark>
that being said
<whitequark>
it seems like you're right, based on what I see in binutils sources
<cr1901_modern>
"it's no longer required as ar takes care of it."
<whitequark>
yes, ranlib is an alias for `ar s`
<whitequark>
but `ar s` *also* doesn't do anything on ELF platforms
<cr1901_modern>
can you upload a minimal example, and I'll test on Net?
<cr1901_modern>
Net uses (a different variant of) ELF, but static libraries are also actually static.
<whitequark>
nevermind I was wrong
<whitequark>
lol, why does misoc pass l to ar
<whitequark>
"This modifier is accepted but not used"
<whitequark>
oh wow the or1k asmparser is a pile of shit
<whitequark>
pity
mithro has quit []
mithro has joined #m-labs
<whitequark>
sb0: is there some way of updating the BIOS that does not involve waiting ~15 minutes for xst?
<whitequark>
sb0: actually, different question first
<whitequark>
is ./make.py load-bitstream supposed to work?
<whitequark>
I've built a BIOS bitstream using gcc, but nothing happens when I load it
<whitequark>
I've also tried to flash-bitstream but it errors out on verification
<whitequark>
does this crap work at all
<cr1901_modern>
I THINK you need a legit JTAG programmer to load the BIOS. You load a proxy bitstream via JTAG onto the FPGA. The proxy lets you write your custom data after the bitstream storage in flash.
<cr1901_modern>
rjo/mithro explained it to me recently. I'll see if I can't find it in the IRC logs
<whitequark>
ohhhhhhhh
<whitequark>
soc.integrated_rom_size is 0 for pipistrello
<cr1901_modern>
Does pipistrello have flash allocated specifically for user purposes?
<whitequark>
soooo from what I can see, yes
<whitequark>
starting at 0x17000 or something
<cr1901_modern>
(still looking for relevant day in chat log)
<whitequark>
sb0: I'm actually not sure that was ever the case
<whitequark>
ranlib, which is equivalent to `ar s`, basically builds an index for the archive
<whitequark>
er, ever the case on ELF platforms
<whitequark>
so that the linker doesn't have to look at the symtab of every .o in turn
<sb0>
(l to ar) copy paste of old makefile. remove it :)
<whitequark>
yeah, let me push...
<sb0>
(flash-bitstream errors) yes, xc3sprog has lots of bugs as mentioned. use fpgaprog, unfortunately not integrated with misoc, or try Robert's openocd
<sb0>
and yes, the BIOS is XIP so you can compile and flash it separately from the bitstream
<whitequark>
sb0: what about the lock bits?
<sb0>
I never had to deal with those
<whitequark>
i mean, it consistently reads out as locked and protected
<whitequark>
probably due to some glitch that broke the SPI frame
<whitequark>
and protected it
<whitequark>
sb0: can you give me write access to misoc
<sb0>
done
<sb0>
won't fpgaprog or openocd reset the lock bits?
<GitHub48>
[misoc] whitequark pushed 2 new commits to master: http://git.io/vYzdu
<GitHub181>
[misoc] whitequark created new-py2llvm (+2 new commits): http://git.io/vYzdz
<GitHub181>
misoc/new-py2llvm 69c2a70 whitequark: common.mak: use clang/clang++ to compile C/C++ sources....
<GitHub181>
misoc/new-py2llvm d03dabb whitequark: common.mak: Pass -fexceptions to clang and clang++....
<whitequark>
I could even add that to xc3sprog
<whitequark>
but
<whitequark>
there is a lock bit that means "the flash is permanently write-protected"
<whitequark>
and it is set
<sb0>
oh, fun
<whitequark>
well, I suppose I could try fpgaprog
<sb0>
well you can compile with integrated BIOS, then you can operate without flash at all
<sb0>
just reload the bitstream every time
<whitequark>
yeah, and what, wait for ten minutes for the bitstream to build?
<sb0>
yes
<whitequark>
well, screw that
<sb0>
but build, not load. load is fast
<whitequark>
I don't care about load, I load once per build
<whitequark>
sigh
<sb0>
you can load the artiq runtime over serial, too
<whitequark>
anyway, as i've said, i ordered replacement flashes
<whitequark>
rev F instead of rev E on board, otherwise identical
<whitequark>
it's not exactly rocket science to replace a SO8
<sb0>
so you really just need to keep a prebuilt bitstream somewhere and reload it as needed
<whitequark>
well, i am working on bios right now
<sb0>
mh, why?
<whitequark>
libbase also needs to be rebuilt with -fexceptions and -fPIC, since it's linked in kernels as well as BIOS
<whitequark>
we could have two different build configurations
<whitequark>
but I would rather have one
<whitequark>
similarly to building *everything* with llvm, and not half with clang and half with gcc
<whitequark>
BIOS builds with clang right now, just not clang -integrated-as
<sb0>
open source CPU = breakage everywhere, as said
<whitequark>
sure
<sb0>
I would be surprised if the DWARF stuff worked
<whitequark>
which is why I am actively trying to keep configuration to a minimum
<whitequark>
one assembler, one linker, one C compiler, one optimizer, ...
<whitequark>
well, the DWARF stuff works now.
<whitequark>
it wasn't hard.
<sb0>
on the board?
<whitequark>
no, I manually verified that the emitted data is correct
<whitequark>
it cannot possibly work on board because i cannot upload it on board.
<whitequark>
well, you've just told me how to upload it, but i didn't consider that until just now
<whitequark>
i would ideally get -integrated-as working too, so that we would only have one single place that emits instructions, instead of clang using binutils and kernel "JIT" using integrated as
<whitequark>
but that's not very high priority
<sb0>
yes, that would be nice
<sb0>
also fewer things to install when deploying ARTIQ development tools
<whitequark>
i can't wait until LLD becomes stable so we can ditch binutils entirely
<whitequark>
maybe i'll try an OR1K linker after september
<sb0>
or lm32, or risc-v ...
<whitequark>
speaking of that
<sb0>
risc-v has the advantage that it's instruction set is fpu-friendly, unlike lm32
<sb0>
*its
<whitequark>
I've had a very good look at the OR1K backend
<whitequark>
which I still consider quite high quality
<whitequark>
I know the plan was to use or1k for comm and lm32 for kernel
<whitequark>
how much do you want that? it would be nice if we could upstream just one ISA to LLVM and support it
<whitequark>
instead of two
<sb0>
it was lm32 for comms and or1k for kernel. and it was a joke :)
<whitequark>
I haven't looked at lm32 backend so far but if it's really as low quality as you say it would be a nontrivial effort to bring up
<whitequark>
oh.
<sb0>
of course we want to deal with only one ISA
<whitequark>
well, joke more carefully :p i almost spent a day studying the ISA and backend
<sb0>
maybe it'll be 100% LM32 later...
<whitequark>
I guess that also works
<whitequark>
is LM32 that much better?
<sb0>
not *that* much. only slightly compared to the recent mor1kx.
<whitequark>
ok, let me take a quick look at the backend then
<whitequark>
god almighty
<whitequark>
can we stick to OR1K?
<sb0>
for now, sure
<whitequark>
uhm. fpgaprog does nothing
<whitequark>
oh, it just doesn't write anything if not verbose
<whitequark>
fpgaprog doesn't seem to work
<whitequark>
Uknown Flash Manufacturer (0x00)
<whitequark>
Error: SPI Status Register [0x00] mismatch (Wrong device or device not ready)..
<whitequark>
I am using it as: ./lin64/fpgaprog -v -b ~/.migen/bscan_spi_lx45_csg324.bit -f ~/Work/artiq-dev/misoc/build/artiq_pipistrello-nist_qc1-pipistrello.bit
<whitequark>
oh, wrong bscan_spi
<whitequark>
sb0: how do you flash BIOS using fpgaprog?
ylamarre has quit [Quit: ylamarre]
<whitequark>
I tried... -a $((0x170000)):artiq-dev/misoc/software/bios/bios.bin
<whitequark>
and it says:
<whitequark>
Bit file does not fit into Flash memory.
<sb0>
well, no, it's clearly failing on the board, there are format strings left there
<sb0>
and yes, this sort of shit is precisely why I stay away from -fPIC and other fancy toolchain features :-)
<whitequark>
in what world -fPIC is fancy?
mithro has joined #m-labs
<sb0>
in open source CPU world where nothing works, basically
aeris has joined #m-labs
<whitequark>
meh
<sb0>
open softcores are nice and portable, but better keep the software simple
<whitequark>
I'm more worried about travis
<whitequark>
oh right. ubuntu 12.04
<whitequark>
can someone do the build according to instructions on that ancient ubuntu? I don't have an image around
<whitequark>
well, I suppose after I fix the linker bug above
<whitequark>
or code generator. whatever it is that has the bug.
felix___2 is now known as felix_
aeris has quit [Quit: en a pas]
<whitequark>
hm, so this works now
<whitequark>
wasn't a toolchain bug.
<sb0>
what was it?
<whitequark>
_GLOBAL_OFFSET_TABLE_ wasn't explicitly defined and I did a static link
<whitequark>
so the linker chose a random address from .got and put it there
<whitequark>
such behavior. much consistency. very reliable. wow.
<whitequark>
anyway, I defined _GLOBAL_OFFSET_TABLE_ and now it finds all the constants correctly
<whitequark>
however, CRC doesn't check out, even though it works otherwise
<whitequark>
probable cause: string constants are using a gotoff relocation, which is basically using the GOT address as "some" known address inside the sharing object, and calculating the .rodata symbol off it
<whitequark>
gotoff relocations are essentially an optimization: you could go from pc every time, but it's twice the instruction count
<sb0>
is the _ftext symbol defined correctly at the end of what gets put into the .bin?
<whitequark>
let's see
<sb0>
er, _edata
<whitequark>
00170000 g .text 00000000 _ftext
<whitequark>
00177bcc g .data 00000000 _edata
<whitequark>
oh
<whitequark>
ohh, _edata. well, this explains
<whitequark>
oh, no, .got is before _edata, so it should work
<whitequark>
as an aside, what is _gp and why do you create it?
<whitequark>
let me rephrase
<whitequark>
is there something that actually uses _gp or is that just a remnant?
<sb0>
just a remnant afaik
<whitequark>
r16 is used in PLT stubs, but LLVM will generate stores to it itself
<whitequark>
and _gp was in the wrong place anyway.
aeris has joined #m-labs
<whitequark>
nevermind, I rearranged the sections and now CRC passes.
<whitequark>
yay, PIC is working.
<GitHub120>
[misoc] whitequark pushed 1 new commit to master: http://git.io/vY2JH
<GitHub120>
misoc/master c8ffd0c whitequark: Switch to -fPIC....
<sb0>
I guess software/libbase/linker-sdram.ld needs a .got entry as well
<whitequark>
oh, yes
<sb0>
ditto linker.ld and ksupport.ld in artiq runtime
<GitHub77>
[misoc] whitequark pushed 1 new commit to master: http://git.io/vY2T6
<GitHub77>
misoc/master 50cf701 whitequark: Update libbase/linker-sdram.ld with -fPIC support.
<GitHub114>
[artiq] whitequark pushed 1 new commit to master: http://git.io/vY2Th
<GitHub114>
artiq/master 1d9f408 whitequark: Update ldscripts with -fPIC support.
travis-ci has joined #m-labs
<travis-ci>
m-labs/artiq#331 (master - 1d9f408 : whitequark): The build has errored.
<sb0>
CRITICAL WARNING: [Netlist 29-53] ISERDESE2 instance 'ISERDESE2_65' has the DATA_RATE attribute set to DDR, but does not use both CLK and CLKB input pins, which is required for DDR mode. This instance will be converted to a black box element.
<sb0>
...of all things to do, convert it to a black box element to ensure obscure error messages later on