_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
hansfbaier has quit [Ping timeout: 240 seconds]
hansfbaier has joined #litex
lf_ has joined #litex
lf has quit [Ping timeout: 264 seconds]
ambro718 has quit [Ping timeout: 256 seconds]
<shorne> ecpix5 looks nice, maybe its time for an upgrade. I need more than 256mb ram for glibc development/testing
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #litex
shorne has quit [Ping timeout: 264 seconds]
<somlo> shorne: just be extra gentle with the micro-usb connector :)
Degi_ has joined #litex
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 246 seconds]
shorne has joined #litex
Bertl_oO is now known as Bertl_zZ
tucanae47 has quit [Ping timeout: 260 seconds]
tucanae47 has joined #litex
levi has quit [Ping timeout: 260 seconds]
levi has joined #litex
_whitelogger has joined #litex
hansfbaier has quit [Quit: WeeChat 2.8]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has left #litex [#litex]
hansfbaier1 has joined #litex
hansfbaier1 has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: No route to host]
hansfbaier has joined #litex
hansfbaier has left #litex [#litex]
ambro718 has joined #litex
ambro718 has quit [Read error: Connection reset by peer]
ambro718 has joined #litex
x56 has quit [Quit: Ծ-Ծ]
x56 has joined #litex
Bertl_zZ is now known as Bertl
peeps[zen] is now known as peepsalot
<somlo> anyone with a working ecpix5 interested in trying the linux-on-litex-rocket bitstream and boot.bin (should load via either sdcard or tftp)? http://mirror.ini.cmu.edu/ecpix5.tar.xz
Zguig has joined #litex
<Zguig> Hi somlo, I saw your misadventures with the USB connectors... I'm sorry for this. There is no way to sold back the connector? Or maybe try to see with the suppliers if they can give another to you...
<Zguig> I will load and check your code on my board
<zyp> somlo, if the usb signals weren't getting through and then the connector fell off way too easily, it sounds like a manufacturing defect, not soldering the connectors properly
<zyp> I'd expect a warranty replacement in your case
<Zguig> Looks good somlo :)
<Zguig> Executing booted program at 0x80000000
<Zguig> --============= Liftoff! ===============--
<Zguig> bbl loader
<Zguig>               vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
<Zguig>                   vvvvvvvvvvvvvvvvvvvvvvvvvvvv
<Zguig> rrrrrrrrrrrrr       vvvvvvvvvvvvvvvvvvvvvvvvvv
<zyp> I'm speaking from experience, I've had similar problems on stuff I've made, e.g: https://bin.jvnv.net/file/Kg4JE.JPG (pins 1 and 4 are not making contact)
<Zguig> rrrrrrrrrrrrrrrr      vvvvvvvvvvvvvvvvvvvvvvvv
<Zguig> rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
<Zguig> rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
<Zguig> rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
<Zguig> rrrrrrrrrrrrrrrr      vvvvvvvvvvvvvvvvvvvvvv
<Zguig> rrrrrrrrrrrrr       vvvvvvvvvvvvvvvvvvvvvv
<Zguig> rr                vvvvvvvvvvvvvvvvvvvvvv
<Zguig> rr            vvvvvvvvvvvvvvvvvvvvvvvv      rr
<Zguig> rrrr      vvvvvvvvvvvvvvvvvvvvvvvvvv      rrrr
<Zguig> rrrrrr      vvvvvvvvvvvvvvvvvvvvvv      rrrrrr
<Zguig> rrrrrrrr      vvvvvvvvvvvvvvvvvv      rrrrrrrr
<Zguig> rrrrrrrrrr      vvvvvvvvvvvvvv      rrrrrrrrrr
<Zguig> rrrrrrrrrrrr      vvvvvvvvvv      rrrrrrrrrrrr
<zyp> nice
<Zguig> [    0.000000] SBI specification v0.1 detected
<Zguig> [    0.000000] software IO TLB: mapped [mem 0x000000009f7fa000-0x000000009f7fa800] (0MB)
<Zguig> [    0.000000] riscv: ISA extensions acdfim
<Zguig> [    0.000000] riscv: ELF capabilities acdfim
<Zguig> [    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<Zguig> [    0.000000] pcpu-alloc: [0] 0
<Zguig> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 128520
<Zguig> [    0.000000] Kernel command line: earlycon=sbi console=hvc0 swiotlb=noforce
<Zguig> [    0.000000] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
<Zguig> [    0.000000] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes, linear)
<Zguig> [    0.000000] Sorting __ex_table...
<Zguig> [    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
<Zguig> [    0.000000] Memory: 499924K/522240K available (3765K kernel code, 3988K rwdata, 2048K rodata, 2880K init, 269K bss, 22316K reserved, 0K cma-reserved)
<Zguig> [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
<Zguig> [    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
<Zguig> [    0.000000] riscv-intc: 64 local interrupts mapped
<Zguig> [    0.000000] plic: interrupt-controller@c000000: mapped 4 interrupts with 1 handlers for 2 contexts.
<Zguig> [    0.000000] random: get_random_bytes called from start_kernel+0x39e/0x556 with crng_init=0
<somlo> Zguig: thanks! did it make it all the way to the busybox shell ?
<Zguig> Yep
<Zguig> # ifconfig
<Zguig> # ls /etc
<Zguig> inittab
<Zguig> # ifconfig -a
<Zguig> eth0      Link encap:Ethernet  HWaddr E6:E7:4C:CC:20:70
<Zguig>           BROADCAST MULTICAST  MTU:1500  Metric:1
<Zguig>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
<Zguig>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
<Zguig>           collisions:0 txqueuelen:1000
<Zguig>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
<Zguig>           Interrupt:2
<Zguig> lo        Link encap:Local Loopback
<Zguig>           LOOPBACK  MTU:65536  Metric:1
<Zguig>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
<Zguig>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
<Zguig>           collisions:0 txqueuelen:1000
<Zguig>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
<somlo> awesome, thanks! I'll update linux-on-litex-rocket to include this
<Zguig> Congrats!
<Zguig> I used OpenOCD to load the firmware and have copied the image on SDCard
<Zguig> openocd -f Research/litex/litex-boards/litex_boards/prog/openocd_ecpix5.cfg -c 'transport select jtag; init; svf ./Téléchargements/ecpix5/ecpix5.svf; exit'
<somlo> Zguig: which of the two USB ports (usb-c, micro-usb) are you using for the console and/or programming?
<Zguig> micro USB...
<tpb> Title: Debug ECPIX-5 Documentation documentation (at docs.lambdaconcept.com)
<Zguig> Only micro usb is able to be used
<Zguig> Or the external JTAG
<Zguig> Haven't tested the external JTAG yet, but I took the JTAG serial board from Lambda concept with the board in case of
<Zguig> Do you have an equivalent?
<Zguig> If you wantI can try with this also
<zyp> somlo, micro-usb goes to the onboard ftdi for debug, usb-c is connected directly to the fpga
<somlo> Zguig, zyp: https://imgur.com/a/DGuIvSL
<tpb> Title: Imgur: The magic of the Internet (at imgur.com)
<somlo> the pads pointed to by the arrow should have been "melted" against the connector better than they were, to keep it in place, which was apparently not the case :(
<zyp> yeah
<zyp> I'd say that's a defect
<somlo> I should follow-up my email to lambdaconcepts to send them this image, in support of my "I didn't abuse the board" claim :)
<geertu> somlo: just needs a little bit of hot air? ;-)
<zyp> should be reasonably easy to hotair it back
<somlo> geertu: I'm not set up to fix this on my end, unfortunately. But it'd be great if the vendor could fix it and restock it, or send it back to me, or whatever :)
<somlo> it's really a very nice idea, hopefully it can be sorted out
<Zguig> I would also say that this is a defect in the board, seems on your picture that the only soldering point were the two small pins
<zyp> I'm really not a fan of the sockets without mechanical tabs going into holes in the board
<zyp> and I don't get why they didn't go with usb-c for the debug port too
<geertu> zyp: yeah, it has more pins to hold the connector (in case you forget to solder the tabs ;)
<zyp> ha
<Zguig> It seems related to the chipset used which is USB2 https://ftdichip.com/products/ft2232hq/
<tpb> Title: FT2232HQ - FTDI (at ftdichip.com)
<zyp> there's no reason to not use usb-c for usb2, there's even a bunch of simplified usb-c sockets on the market that only implements the pins used by usb-2
<Zguig> but then no way to have usb 3 speed, isn't it?
<Zguig> Maybe just wanted to keep the logic usb micro => usb2 et usb c => usb3?
<Zguig> or maybe it is not related at all and it is only the manufacturers that did this association?
<zyp> it's not related at all, usb-c can do anything
<somlo> updated https://github.com/litex-hub/linux-on-litex-rocket (and the pinned issue with pre-built blobs) for ecpix5; Zguig, thanks again for running the tests!
Bertl is now known as Bertl_oO
Bertl_oO is now known as Bertl
Zguig has quit [Quit: Ping timeout (120 seconds)]
<zyp> somlo, this actually looks like a design mistake: https://bin.jvnv.net/file/Rohhx.jpg
<zyp> socket is pulled a bit too far back, the flange is designed to protrude past the board edge
david-sawatzke[m has quit [Ping timeout: 244 seconds]
david-sawatzke[m has joined #litex
kgugala has quit [Remote host closed the connection]
nickoe has joined #litex
<nickoe> hello
<nickoe> Seeing https://github.com/timvideos/litex-buildenv/blob/master/platforms/basys3.py it looks like there is a migen platform def for the basys3
<nickoe> But how do I build that, just sourcing the env and doing make gateware does not work.
<nickoe> I used, export PLATFORM=basys3; source litex-buildenv/scripts/enter-env.sh and get a console: (LX P=basys3 C=vexriscv)
<nickoe> from what path should I be able to do "make gateware"?
<mithro> nickoe: In the litex-buildenv directory
<nickoe> mm, ok
<nickoe> I think it did synth something
<nickoe> but make gateware-load (not make load as on the wiki) fails
<nickoe> embedded:startup.tcl:26: Error: Can't find board/digilent_basys3.cfg
<nickoe> from openocd
<nickoe> I guess
<nickoe> mithro: Do I need to set the CPU for he basys3 board, or is the default of vexriscv ok?
<mithro> default should be fine
<mithro> nickoe: Log a bug about the openocd error
<nickoe> mithro: and this is the correct repo? https://github.com/timvideos/litex-buildenv
<nickoe> mithro: I used the one specifed on https://symbiflow-examples.readthedocs.io/en/latest/building-examples.html for flash ing before
<tpb> Title: Building example designs SymbiFlow examples documentation (at symbiflow-examples.readthedocs.io)
<nickoe> share/openocd/scripts/board/digilent_arty.cfg
<nickoe> and that is available in the ocd checked out
<nickoe> ok, usin that cfg it did flash and I see the litex
<nickoe> bios
<nickoe> mithro: v
<nickoe> how does that flterm work? I did make firmware-load and it is stuck at "[FLTERM] v2.4-29-g47d3b15 Starting..."
<mithro> nickoe: Hit enter?
<nickoe> then what?
<mithro> nickoe: Did a prompt appear?
<nickoe> yes
<nickoe> is there supposed to be some other firmware running than in the "bios?
<mithro> Did you load some other firmware?
<nickoe> I just did make firmware-load
<mithro> nickoe: Type "serialload" possible then?
<tpb> Title: dpaste: 5DE66S2UZ (at dpaste.com)
<mithro> nickoe: That log shows you as having typed `make firmware-connect-basys3`not `make firmware-load` ?
<nickoe> oh, well, I don't see any difference anyway
<mithro> `make firmware-load` will load firmware when it sees the serialboot prompt
<nickoe> mm
<nickoe> here you go https://dpaste.com/C8EEKSR4Q
<tpb> Title: dpaste: C8EEKSR4Q (at dpaste.com)
<nickoe> It still sort of errors.
<nickoe> mithro: I am not really sure what to expect, but that looks like something is not quite right to me
<mithro> nickoe: Can you log an bug about the `[FLTERM] Unable to open kernel image (request ignored).: No such file or directory` line?
<mithro> nickoe: Can you check to see if `build/basys3_base_vexriscv/software/firmware/firmware.bin`exists?
<mithro> Looks like there is some confusing about if the firmware you are using is the stub firmware or not
<nickoe> ./build/basys3_base_vexriscv/software/stub/firmware.bin: data
<nickoe> file ./build/basys3_base_vexriscv/software/stub/firmware.bin
<mithro> nickoe: stub != firmware (yes there is firmware called stub and firmware called firmware)
<nickoe> ??
<nickoe> What do do to make it run some firmwarE?
<mithro> Try "export FIRMWARE=stub" and then `make firmware-load` again
<nickoe> if I dod that and type serialboot then it looks like it is doing stuff, at lesat it is showing some progress in the form of a percentage.
<nickoe> [FLTERM] Received firmware download request from the device.
<nickoe> 44%
<nickoe> [FLTERM] Uploading kernel (7848 bytes)...
<nickoe> mithro: is that "stub" fw supposed to do anything?
<mithro> It's only a little more advanced than the bios -- I think you can toggle LEDs and stuff
<nickoe> I don't get a console
<nickoe> it is just like this, even if I hit enter a couple of times, https://dpaste.com/66QCEYGNN
<tpb> Title: dpaste: 66QCEYGNN (at dpaste.com)
flammit_ has joined #litex
pdp7_ has joined #litex
<nickoe> mithro: So what to do now?
<mithro> nickoe: Sounds like there might be a gateware / firmware mismatch or some other issue
<nickoe> Is it correct that it should use stub fw?
<mithro> nickoe: I don't know if anyone has been using the basys3 much
<mithro> Generally the stub firmware is used on boards which don't have external DDR memory
<nickoe> ok, and I guess that is true in this case with the basys3.
<mithro> Generally the basys3 isn't a great fit for the type of things that LiteX-BuildEnv tends to target...
<nickoe> I don't need a big softcpu, just a small one to run a bit of code on to be able to interface with serial for example and write to a few regs.
<mithro> nickoe: That is what the stub firmware does
<nickoe> but how can I figure out why it does not run?
<nickoe> I am using vivado 2020.2 btw
pdp7 has quit [*.net *.split]
flammit has quit [*.net *.split]
flammit_ is now known as flammit
pdp7_ is now known as pdp7
kgugala has joined #litex
<nickoe> mithro: Should I be able to run the micropython interpreter fw on the basys3?
<nickoe> it does not seem to create build/basys3_base_vexriscv/software/micropython when building with make firmware and I have export FIRMWARE=micropython
<mithro> nickoe: I'm unclear what is being used as the "main memory" on the basys3 -- as it doesn't have external DDR or the big SP RAM blocks that the ice40up5k has...
<nickoe> the only diffrence on that seems to be that it sets TARGET, is that required?
<mithro> nickoe: You have to use the `./scripts/build-micropython.sh`
<mithro> nickoe: As the micropython build system is outside the normal litex-buildenv system
<nickoe> mm, ok, I would have dhough that the download-env-sh script would take care of that when sourced
<nickoe> into an env with the FIRMWARE=micropython
<nickoe> mithro: it errors with https://dpaste.com/5895SX24T
<tpb> Title: dpaste: 5895SX24T (at dpaste.com)
<nickoe> (LX P=basys3 C=vexriscv F=micropython) [nickoe@x280-arch litex-buildenv]$ ./scripts/build-micropython.sh .... that is
<mithro> nickoe: I can't see enough of the output to confirm that you are running what I expect
<nickoe> but at least there is that micropython build folder and a subsequent make firmware-load and serialboot seems to do something
<nickoe> mithro: Output of what?
<mithro> In that above pastebin
<nickoe> right now it appears to flash a min from the micropython folder flterm --port=/dev/ttyUSB1 --kernel=build/basys3_base_vexriscv/software/micropython/firmware.bin --speed=115200
<nickoe> [FLTERM] v2.4-29-g47d3b15 Starting...
<nickoe> Command not found
<nickoe> s
<nickoe> litex>
<nickoe> litex> serialboot
<nickoe> Booting from serial...
<nickoe> Press Q or ESC to abort boot completely.
<nickoe> sL5DdSMmkekro
<nickoe> [FLTERM] Received firmware download request from the device.
<nickoe> [FLTERM] Uploading kernel (218752 bytes)...
<nickoe> 2%
<nickoe> wopps
<nickoe> I meant to paste https://dpaste.com/CM532M73Y
<tpb> Title: dpaste: CM532M73Y (at dpaste.com)
<mithro> I expect it'll fail
<nickoe> mithro: Sorry, but I am not sure what output you are refferint to for the tail of the output of ./scripts/build-micropython.s
<nickoe> *reffering
<nickoe> oh, referring :D
<nickoe> if just I could spell
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<mithro> Given the current state of things the basys is just *not* a good platform to be used here -- There are just too many things on the basys board that do not work like every other platform
<nickoe> Why is it that different?
<nickoe> Or rather, what makes it that different?
<mithro> nickoe: I'm unclear what is being used as the "main memory" on the basys3 -- as it doesn't have external DDR or the big SP RAM blocks that the ice40up5k has... <------
<nickoe> As far as I understand it.
<nickoe> I have this board as well, https://www.enclustra.com/en/products/fpga-modules/mars-ax3/ , but I am waiting for a JTAG for it
<tpb> Title: Enclustra FPGA Solutions | Mars AX3 | Xilinx Artix-7 28nm FPGA Module | 7A35T | 7A50T | 7A100T (at www.enclustra.com)
<nickoe> Maybe I could do more in simulation for that somehow?
<mithro> nickoe: The Arty A7 is the best / most well tested platform for a beginner who wants to use Xilinx Artix-7
<nickoe> yeah, well, but unfortunately I don't have one of those :(
<nickoe> same issue with that as you predicted.
<somlo> zyp: thanks, that makes sense... either way, I emailed my picture and story to the folks at lambdaconcepts, we'll see if/when they get back to me
<nickoe> mithro: the AX3 appears to have a XC7A35T-1CSG324I
<nickoe> somlo: Story?
<nickoe> not sure what the -1 before the CSG means.
<zyp> speed grade 1
<nickoe> xc7a35tcsg324-1 ... but that is the same -1 as the notation used in prjxray-db?
<zyp> that sounds likely
<nickoe> ok
<somlo> nickoe: not a very exciting story -- I ended up damaging the micro-usb port on my ecpix5 due to some weak soldering done by the PCB shop that ended up fabricating the board
<nickoe> mm, shite happens
<zyp> somlo, looking at it, I won't be surprised if mine ends up suffering the same fate
<daveshah> Yep tabs on mine look a bit ropey too
<nickoe> is it surface mount only?
<daveshah> yeah
<daveshah> which can be OK if done properly (e.g. the icebreakers)
<nickoe> are the pads too small on the ecpix5?
<daveshah> looks like the solder just didn't attach well for some reason
<zyp> daveshah, because the socket is not located properly, the flange should have been past the board edge: https://bin.jvnv.net/file/Rohhx.jpg
<nickoe> ugh
<nickoe> would have been nicer with usb c :D
<zyp> absolutely
<nickoe> even if just usb 2.0
<zyp> that's why they make 14-pin usb-c sockets
<nickoe> just remember to connect both "sides" of the d+ and d- lines on the board