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
fengling has joined #m-labs
<mindrunner>
what are the differences between loading my software chainloaded through the bios and booting it up directly. I am getting slower uard throughput when not using the bios. what can the reason for that be?
<sb0>
what do you mean by booting directly? execute from flash?
<mindrunner>
I modified my makefile, and flashed to the bios address
<mindrunner>
instead of flashing to the address where the bios looks for my fbi file and loads it
<mindrunner>
know what I mean sb0?
<mindrunner>
sort of being my own bios
<sb0>
so yes, execute from flash. and did that make the uart go faster?
<sb0>
I assume you have modified the linker script as well
<mindrunner>
yeah, i used the linker.ld from bios instead of linker-sdram.ld
<mindrunner>
when using direct method, my uart throughput is about 170kb/s, booting from bios gives me about 210kb/s
<sb0>
what sdram configuration are you using?
<mindrunner>
how can I find out? I suppose its default
<sb0>
what target are you building?
<mindrunner>
pipistrello
<sb0>
ah it's lasmi with l2
<sb0>
you might have a bad case of l2 cache thrashing between instructions and data. try increasing the l2 size.
<sb0>
or the cpu cache size
<sb0>
and in either case - again this uart design is not optimized for performance. if you want throughput, use dma, larger buffers, etc.
<mindrunner>
yes, i would like to. but i am kind of struggling finding out how. in the end, i am still using uart to communicate with the attached computer, dont I? or what interface am i supposed to use between the pipistrello and my computer?
<sb0>
as I said before, the uart design in misoc generates one IRQ per char. this will use a lot of CPU resources on the lm32/or1k at high throughput.
<sb0>
you need to redesign the cpu interface of the uart so that it supports dma, or parses and stores packets in bram, or whatever design you imagine
<sb0>
which pretty much depends on your application
<mindrunner>
ah, okay. so replacing the misoc uart controller is what i need? was there anything similar being done which is open source?
<sb0>
and plug your own protocol decoder/DMA engine/whatever
<sb0>
there are questions such as, "should it use IRQs" that only you can answer
<mindrunner>
yeah, though I dont feel expert enough to answer all my questions ;)
<sb0>
well, what kind of data do you want to transfer and at what speed?
<sb0>
and when?
<mindrunner>
i am reading raw data from a NAND flash which is connected to the io pins. the main goal is to be able to dynamically configure the pins according to the connected NAND flash and read the complete flash for storing it into an image file
<mindrunner>
i think the maximum possible throughput would be best
<sb0>
a simple solution to achieve higher throughput for this application is to use the uart without the irqs, which aren't really needed here afaict
<sb0>
this way you don't need to modify the gateware
<mindrunner>
cool
<mindrunner>
how do i turn them off
<sb0>
by writing a new uart driver that doesn't use them
<mindrunner>
:)
<sb0>
this may be premature optimization though, isn't the existing driver good enough for a prototype?
<mindrunner>
considering the fact, that i will run out of time soon, i think i should go for the current solution (depending on what effort it is to modify the uart)
<mindrunner>
reading 1gb NAND still needs more than one hour
<mindrunner>
and there is lots of stuff I dont understand yet (throughput differences bios/no-bios, getting weird 0-bytes, etc)
<sb0>
yes, you may need to sit down and look into those
<sb0>
though I wouldn't spend much time on the zero-byte issues if the culprit turns out to be ftdi.
<sb0>
getting misbehaving ftdi stuff to work is usually a lost cause
<mindrunner>
its kind of working since two days. but i dont know why
<mindrunner>
which really sucks.
<cr1901_modern>
In function `uart_isr':
<cr1901_modern>
uart.c:(.text+0x14): undefined reference to `uart_ev_pending_read'
<cr1901_modern>
Why thank you for that helpful error, gcc. I DID set with_uart to False XD
jaeckel has quit [Remote host closed the connection]
<GitHub60>
[migen] sbourdeauducq pushed 3 new commits to master: http://git.io/vf8z4
<_florent_>
I'm using it for something almost similar: uploading logic analyzer datas
<sb0>
hi _florent_
<sb0>
I'm seeing a lot of TCP retransmission (every frame, basically) when the connection gets slow
<_florent_>
hi
<_florent_>
what do you mean by "connection gets slow"?
<sb0>
the test is simply to send some data to an open connection to the board, and look at it with wireshark
<sb0>
you should see there is an abnormally high amount of TCP retransmissions from the PC to the board
<sb0>
I mean a TCP connection between the board and PC will transfer a few hundred bytes per second (due to lots of dropped packets I guess)...
<_florent_>
what's the speed link? (100Mbps or 1Gbps?)
<sb0>
100M
<_florent_>
OK
<sb0>
should I try at 1G?
<sb0>
the netboot isn't slow on the other hand, so I guess liteeth behaves
<_florent_>
not that was just to know (I think 1G should do more retransmissions)
<sb0>
I can load and run kernels now over ethernet btw :) (if I'm patient)
<_florent_>
I should maybe add a counter on liteeth when packets are dropped because there is no available slots
<_florent_>
is is that slow?
<whitequark>
sb0: nice. how'd you do it before?
<whitequark>
uart?
<sb0>
I don't think that's the problem
<sb0>
there are two slots right?
<_florent_>
yes
<sb0>
in my wireshark trace I see a ACK packet from the board in response to the SYN
<sb0>
then the OK from the PC, then the first data packet, then the data retransmission
<sb0>
the liteeth core should have been able to buffer the OK and the first data packet
<sb0>
and I don't see any network broadcasts in-between
<sb0>
whitequark, yes UART
<sb0>
_florent_, and yes, it's super slow. at least one order of magnitude slower than uart *g*
<sb0>
at least half the packets get dropped or something afaict
<whitequark>
reminds me of soho routers. updated a few of them via tftp, was slow as molasses
<whitequark>
amusingly, one of them started to behave when i ran a ping -f concurrently with the tftp update
<whitequark>
finished it in a few seconds
<whitequark>
to this day i am curious where they managed to screw up
<sb0>
whitequark, the wifi card on my lenovo tablet has a similar bug
<sb0>
delays incoming packets by several seconds, unless a ping -f or similar traffic generator is running
<whitequark>
huh
<sb0>
I guess the power management is buggy, but disabling it didn't help
<sb0>
this tablet demonstrates the most incredible amount of linux kernel bugs
<sb0>
nothing works correctly, except USB
<sb0>
and by "nothing", I mean really nothing - every component (screen, hdd, acpi, ...) has some sort of bug
<whitequark>
impressive
<whitequark>
in a sad sort of wy
<sb0>
oh and the sdram works fine, too. but that's about it.
<sb0>
I have workaround for certain things, so it's a usable machine, but annoying and frustrating
* whitequark
has an ux32vd pc
<whitequark>
it's been great, except the battery is dead now. i ordered one from china but the laptop declines to accept it
<whitequark>
some kind of gross 'smart' battery
<sb0>
_florent_, a "ping -f" doesn't seem to have any significant impact on the tcp connections
<sb0>
whitequark, oh yes, I forgot to mention that the machine was heavily loaded with spyware (and good thing lenovo got sued for that) and had the computrace shitware in the bios
<_florent_>
ok, I'm going home and will do a throughput onboard test with lwip and fix the others thing you told me
<_florent_>
bye
_florent_ has quit [Quit: Leaving]
<whitequark>
sb0: oh one of the new ones. gross.
<whitequark>
I'm seriously considering to stack on pre-2014 PCs
<whitequark>
you know, without the intel management engine crap and such
<whitequark>
ahah, the 3rd ebay line for "ux32vd" is "new dc power jack". been there, desoldered it
<sb0>
whitequark, ah yes. when I started messing with the EFI boot, windows detected a tampering attempt and required me to register with microsoft and get an unlock code for the machine ...
<whitequark>
wtf
<whitequark>
can't you disable secure boot in setup?
<sb0>
there's also this stupid "rpmb" DRM partition on the hdd which is the only one I haven't erased yet
<whitequark>
or install a cert or w/e it wants
<sb0>
whitequark, you can. but doing so makes windows refuse to boot unless you get that unlock code as well
<sb0>
whitequark, modifying certs also causes that
<sb0>
also the first boot process is funny. if you had set up an internet connection at that time, windows will ask you for your personal details and refuse to proceed until you have done so
<sb0>
first booting with the wifi disable circumvents that
<whitequark>
amazing
<whitequark>
that's 8.1?
<sb0>
yes, "with bing" (I took the cheapest option as I have no intention of running windows...)
<whitequark>
i haven't even bothered to boot windows once on this machine
<whitequark>
dunno what it was
<GitHub102>
[artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/vf4OB
<GitHub102>
artiq/master bf935ba Yann Sionneau: travis: install cython via conda to save time