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
<cr1901_modern>
Figured out what I was doing wrong; I attached the wrong object as a submodule; I wrapped the csrgen bank in another class which didn't have any self.comb or self.sync
<cr1901_modern>
and then attached the wrapper class as a submodule. So nothing got generated
<cr1901_modern>
sb0: I'm guessing "no", but is it possible to generate a little-endian CSR bus such that atomic writes work properly?
<cr1901_modern>
(This is not for LM32- I'm playing with Migen to get a feel for it for an unrelated project)
<sb0>
possible yes, implemented no
<cr1901_modern>
Can't be that tough to implement... in any case, my little project in question interfaces to a 16-bit little endian chip. So, I'll add it at some point soon
<cr1901_modern>
DIR_M_TO_S/DIR_S_TO_M control the direction of bits, don't they?
<cr1901_modern>
wait nevermind- that doesn't explain DIR_NONE
<cr1901_modern>
DIR_M_TO_S == DIR_MASTER_TO_SLAVE... bleh, took me long enough
bentley` has quit [Remote host closed the connection]
<ysionneau>
synthesis worked in my VM with 3.5 GB of RAM, let's try with only 3 GB :o
<ysionneau>
ah yes, during the build my VM comes very close to the 3 GB limit
<ysionneau>
the Xilinx reporting tool says peak memory used by the build process is 2410 MB
<ysionneau>
I wonder if there is a way to say to Xilinx tools "please use less RAM"
<acathla>
Xilinx answer would be : "LOL"
* ysionneau
trying to reduce the thread number to 1
<sb0>
ysionneau, if that's a pain, maybe a good option is to disable the bitstream builds in travis (but keep support for them in the conda scripts)
<ysionneau>
yes, so that we can still generate "releases" which contain the binaries.
<ysionneau>
it's really annoying, it almost works, it's just a RAM issue ...
<sb0>
or maybe try asking travis to increase the RAM limit...
bentley` has joined #m-labs
_florent_ has joined #m-labs
fengling has quit [Ping timeout: 252 seconds]
fengling has joined #m-labs
<cr1901_modern>
Pretty sure acathla hit the nail on the head there
<whitequark>
have you considered setting up a buildbot yourself?
<whitequark>
don't have to install xilinx tools anew too
<ysionneau>
since travis provided a very easy to use platform for that, no dev or server administration/fees needed, nop
<ysionneau>
but since travis no longer fits ... maybe that could be a solution
<cr1901_modern>
Can't speak for others, but buildbot is not user friendly at all for me. Very tedious to set up properly
<cr1901_modern>
I tried using it to set up daily NetBSD builds. Gave up and went back to cron and a shell script
<whitequark>
I have set buildbot up
<whitequark>
it's not /perfect/, but it works with relatively little hassle (a few days took me, at most) and it's not, ugh, Jenkins
<whitequark>
where you need someone full-time to just figure out all the XML (not being sarcastic)
<ysionneau>
ah buildbot is some already existing project
<cr1901_modern>
^Well, yes :P. Maybe I should give it another time
<ysionneau>
didn't know that
<cr1901_modern>
chance* even
<whitequark>
yeah, it's a python thing
<whitequark>
I've my old scripts lying around, so I should be able to set it up even quicker this time
<cr1901_modern>
whitequark: I have trouble thinking of two projects that uses XML configuration that's pleasant to set up. Only exception for me is Jedit
<whitequark>
I don't care about XML, Jenkins is just massively overengineered
<sb0>
it's quite remarkable how fucked RMB is. converting it takes 7 hours, transferring it within Hong Kong and within the same bank seems to require special authorizations, ...
<sb0>
I wonder what percentage of the chinese economy rests on "agents" who take care of that bullshit for you
<ysionneau>
first successful synthesis of kc705 with vivado on travis: https://travis-ci.org/fallen/artiq/builds/62214640 Don't know if I was just lucky this time or if my set_param general.maxThreads 1 really helped
<ysionneau>
free physical mem went down to 4 MB at the peak :/
<ysionneau>
1595 MB peak memory usage
<sb0>
ysionneau, that will probably break when we make changes to the bistream
<sb0>
ysionneau, it might be possible to ask for more memory?
<ysionneau>
I asked a few questions on #travis but no one answered so far :/
<ysionneau>
even though the @ people push commits
<whitequark>
ask the travis support
<ysionneau>
let's try that
<whitequark>
support@travis-ci.com
<ysionneau>
thanks
<ysionneau>
done
<cr1901_modern>
ysionneau: How does one use an MMU (looking at mmu.rst in MiSoC) without a present bit for pages? I have a guess, but...
<GitHub115>
[artiq] fallen pushed 1 new commit to master: http://git.io/vUgOh
<GitHub115>
artiq/master 0f9bc7b Yann Sionneau: travis: conda-build and jinja2 must be installed in the root environment
<GitHub92>
[migen] fallen pushed 1 new commit to master: http://git.io/vUg3O
<GitHub92>
migen/master c1088f4 Yann Sionneau: travis: get-anaconda.sh does not take args anymore
<ysionneau>
present bit can be in the PTE in the OS
<cr1901_modern>
that was my guess
sturmflut2 has joined #m-labs
<ysionneau>
if present bit means "page is on disk but not in ram" then in a very basic mmu which does only translate virtual memory addr to physical memory addr
<ysionneau>
then it means data is not in main memory, therefore you just don't map it in the TLB
<sturmflut2>
sb0: Hey, do you still own that Lenovo BayTrail tablet?
<ysionneau>
you let the OS trap because of a TLB miss, and when the OS looks up the PTE it sees the value of present bit and can fetch from disk and update the TLB
travis-ci has joined #m-labs
<travis-ci>
m-labs/migen#28 (master - c1088f4 : Yann Sionneau): The build was broken.
<ysionneau>
(or maybe I'm not up to date enough ...)
<cr1901_modern>
the Mercury board can fit LM32 (and the simple MiSoC design) if I remove the onboard RAM from MiSoC, and disable LM32's cache.
<cr1901_modern>
I wonder if it's possible if I can just create a small bootstrap program that reads the Flash memory to get the rest of the ROM routines, and stores it in the onboard SRAM?
<cr1901_modern>
I'd love to remove some of the space dedicated to ROM on the FPGA and dedicate it to extra hardware. Mercury is a weird board
<ysionneau>
you could write a SRAM controller (that should be very straight forward) and plug it instead of the SDRAM controller
<ysionneau>
then put the bios in flash and it should just work
<ysionneau>
or I'm missing something?
<cr1901_modern>
MiSoC, as far as I can tell, wants me to initialize a ROM and RAM memory on the FPGA itself- it'll error out if I don't
<cr1901_modern>
I want to eliminate the RAM and make the ROM as small as possible because the FPGA is really too small to be used for memory
<cr1901_modern>
So I figured I could have a small "on-die" bootstrap which talks to the Flash ROM and moves the BIOS to SRAM
<cr1901_modern>
and the remainder of SRAM (512kB minus 32kB BIOS) becomes the system RAM
<ysionneau>
which target are you using?
<ysionneau>
why do you want to move the Bios from flash to SRAM when you can execute it in place (XIP) (execute from flash)?
<cr1901_modern>
it's an SPI Flash XD?
<cr1901_modern>
and a modified simple.py
<ysionneau>
SPI Flash can very well do XIP
<ysionneau>
that's what we use so far on kc705/pipistrello/papilio pro etc
<ysionneau>
cr1901_modern: can you publish your code somewhere? (github?)
<GitHub126>
[migen] enjoy-digital pushed 2 new commits to master: http://git.io/vU2eb
<GitHub126>
migen/master 88a406e Florent Kermarrec: migen/genlib/misc: replace Timeout with WaitTimer from artiq
<GitHub48>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/vU2vU
<GitHub48>
misoc/master d9b15e6 Florent Kermarrec: cores: replace Timeout with new WaitTimer
<cr1901_modern>
Will do in a second. Let me just confirm it builds
<ysionneau>
ok :)
<ysionneau>
16:09 < cr1901_modern> MiSoC, as far as I can tell, wants me to initialize a ROM and RAM memory on the FPGA itself- it'll error out if I don't < if you just let integrated_rom_size and integrated_main_ram_size be 0, then you will get rid of both onchip sram and onchip rom
<cr1901_modern>
Number of Slices: 1747 out of 1792 97% (!!)
<cr1901_modern>
Oh, and I've disabled the cache in lm32_config.v, and converted the multiplier/barrel shifter to be unpipelined
<cr1901_modern>
So yes, it'll fit, but it's a snug fit
<cr1901_modern>
If I set integrated SRAM to 0, I get: CPU needs a sram to be registered with SoC.register_mem(). Which means I probably have to build the SRAM controller
<ysionneau>
ah yes, you cannot just disable the onchip sram, you need to provide the controller for off-chip sram
<cr1901_modern>
Same with the flash-ROM?
<cr1901_modern>
BIOS*
<ysionneau>
you need to do your own class which inherits from SoC but overrides do_finalize()
<ysionneau>
and in this do_finalize you can instanciate your SRAM controller and plug it to the wishbone bus
<ysionneau>
you can call your class SRAMSoC and put it in misoclib/sram.py for instance
<ysionneau>
so that it's reusable for other boards with off chip SRAM
<_florent_>
cr1901_modern, ysionneau: in fact you can use the SoC class (and its do_finalize), it's just that you have to provide your rom and sram and register it with register_rom, register_mem
<cr1901_modern>
I'll take a look into that in a bit. Mercury is a weird board. The serial port in fact talks over SPI (and for that matter, the FTDI chip is the SPI master, the FPGA the slave). SRAM and the 5V GPIO are shared. So an SRAM controller is actually not just "plug wishbone connections into the SRAM"
<ysionneau>
ah right
<cr1901_modern>
it has to have logic to switch the bus between the SRAM and the GPIO. Not sure offhand how to make that independent of the controller :P.
<ysionneau>
wowo
<ysionneau>
wierd indeed
<ysionneau>
but yes _florent_ is right, you can use the SoC class in fact
<cr1901_modern>
I'll have to ask the guys who made the board how to use the FTDI serial port. The FPGA being an SPI slave implies that the FPGA only sends data back when the FTDI serial master sends data.
sb0_ has joined #m-labs
<sb0_>
sturmflut2, yes
<sturmflut2>
sb0_: Intel seems to have patched the eMMC issue in their latest Android-x86 kernel, see http://git.android-x86.org/?p=kernel/common.git;a=commit;h=df2f12ff0c7985e1164ac197623ccb32e761ccc7
<sturmflut2>
sb0_: They already tried to upstream it, but it got declined in its current form
<sb0_>
Intel had already sent me this patch, and it doesn't fix my problem
<sturmflut2>
sb0_: Okay, I'll try it on my ThinkPad Tablet 8, but it probably won't fix that too
<sb0_>
I'm beginning to suspect it's some weird interaction between the eMMC, SDIO wifi, SD card and/or MMC controller
<sturmflut2>
Couldn't they "just" look at their Windows drivers and spot the differences?
<sb0_>
don't know... this has been going on for months
<GitHub82>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vU2RX
<GitHub82>
artiq/master a62ae1d Sebastien Bourdeauducq: test/transforms: adapt to 'now' save on core device
<sb0_>
the acpi battery monitor is broken too, which they can reproduce (unlike the eMMC bug, but I'm not sure they have tried hard enough), still unfixed
<cr1901_modern>
ysionneau: Sent my question to the company that makes the board... will take a nap and see if they get back to me XD
<sb0_>
also, for some reason they seem not to have the sources of their own DSP firmware that is contributing to breaking the audio right now
<sb0_>
it all looks a bit messy
<sb0_>
recently broadcom uploaded the firmware for the wifi card to the kernel repos
<sb0_>
this one somewhat works, except there is a delay of several seconds when attempting to receive packets when the card is sleeping
<sb0_>
I
<sb0_>
I'm running 3.14.41 right now which doesn't have the eMMC bug with debug_quirks2=0xc0
<sb0_>
but also, no sdio devices
<sturmflut2>
sb0_: It's very strange that Intel doesn't just go and fix this. Their Linux support is usually quite good, but BayTrail is horrible. The first SoCs in this product family are now two years old.
<sb0_>
sturmflut2, I got the machine to emit some sound under linux btw
<sb0_>
the audio codec chip is in fact a rt5670 unlike what the ACPI tables say
<sb0_>
I wrote a driver based on byt-rt5640 that took the audio routes from cht_bsw_rt5672
<sb0_>
and when that is loaded, it emits (uncontrollable) noise
<sturmflut2>
sb0_: Oh, cool! Is it public?
<sb0_>
also, the alsamixer stuff is completely messed up, but this seems to have everything to do with the crappiness of the baytrail drivers and not much with my hack
<sb0_>
sturmflut2, you want to debug it?
<sb0_>
it might be hard, as the closed-source DSP firmware might be part of the problem
<sb0_>
also there's no info on how the rt5670 codec is hooked up inside the tablet
<sb0_>
it's even improperly identified as a rt5640 in the acpi tables
<sb0_>
other changes required are (from the alsa mailing list):
<sb0_>
1. Hack add "10EC5640" to rt5670.c
<sb0_>
2. Add a new machine driver sound/soc/intel/sst-acpi.c/byt-rt5670
<sb0_>
I guess cht_bsw_rt5672.c can be used as a starting point for audio routes and byt-rt5640.c for dai link definitions.mess
<sb0_>
3. Hack change sound/soc/intel/sst-acpi.c so that "10EC5640" loads the new machine driver instead of byt-rt5640.
<sb0_>
also remove 10EC5640 from rt5640.c
<sturmflut2>
I'll note that for later. I'm still trying to find out what changed in more recent kernels and caused this problem. It's a regression and seems to not only affect BayTrail.
<sb0_>
what, the eMMC bug?
<sturmflut2>
Yes, people with normal SD cards seem to get similar errors with more recent kernels.
<sb0_>
ah, cool, there might be a reasonable chance this horrible bug gets fixed then
sb0_ has quit [Quit: Leaving]
felix__ has joined #m-labs
felix_ has quit [Ping timeout: 264 seconds]
felix__ is now known as felix_
kyak has quit [Remote host closed the connection]
SturmFlut has joined #m-labs
<SturmFlut>
sb0: re. I am now running the 4.0 Android-x86 kernel from Intel on my BayTrail tablet and no eMMC lockups after an hour. Their tree contains a large number of mmc patches and other stuff, something in there must be the solution.
_florent_ has quit [Ping timeout: 272 seconds]
_florent_ has joined #m-labs
mumptai has joined #m-labs
_florent_ has quit [Read error: Connection reset by peer]
SturmFlut has quit [Ping timeout: 246 seconds]
mumptai has quit [Remote host closed the connection]