| lkcl | markos_, if you were using vivado it would always be "simple" | 00:15 |
|---|---|---|
| lkcl | but when using FOSS FPGA tools you simply don't have the luxury of saying "i want to use one tool just like in the commercial world and if it fails i give up". and yes, openocd *is* simple. | 00:16 |
| lkcl | you need to progress from one thing to the next. if you have an LED working that means the bitstream is programmable. | 00:17 |
| lkcl | the next step would be to get blinky running (this will tell you that the PLL is properly programmed), and after that the hello_world uart example | 00:18 |
| lkcl | all of this is far, far eaiser if you are "just" prepared to use the proprietary FPGA tools. | 00:18 |
| *** octavius <octavius!~octavius@92.40.169.142.threembb.co.uk> has quit IRC | 01:09 | |
| *** yambo <yambo!~yambo@184-167-135-012.res.spectrum.com> has joined #libre-soc | 01:41 | |
| markos_ | lkcl, I'm a practical person and I pick my battles, plus it's a matter of experience. For you or cesar, it might be a couple of days/hours to get this board working with open source tools, because you have done fpga for years. For me, it's been just a few days and I just cannot allocate more time on something I know someone more experienced will take just a couple of hours | 09:11 |
| markos_ | because I may be interested in learning -some- fpga development, but not interested in investing my time to enabling those said fpga to use only open source tools | 09:12 |
| markos_ | I already have too many things to worry about | 09:12 |
| markos_ | I will definitely prefer spending a couple hundred euros to get a known working fpga than wasting my precious time getting the nexys video working, I'm already close to burnout as it is | 09:15 |
| *** cesar <cesar!~cesar@2804:14d:688a:59ea:bd4e:1a53:81fb:ba0> has joined #libre-soc | 09:30 | |
| cesar | markos_, does the oled display show something, or just the green led? | 09:35 |
| cesar | Is it possible to give me SSH access to some machine connected to the board by USB? | 09:38 |
| markos_ | that's going to be hard, at least now, it's connected to my laptop now, I can prepare another system for this purpose, but I can't do it atm | 09:39 |
| markos_ | reg oled, by default it has the nexys video demo application | 09:40 |
| markos_ | and it shows temperature/voltage/ip address in the oled | 09:40 |
| cesar | Just for the record, it keeps this way after transferring that system_wrapper.bit? | 09:43 |
| markos_ | yes | 09:43 |
| markos_ | I think I pressed reset at one point | 09:44 |
| markos_ | so it probably reset the programming to the factory default? | 09:44 |
| markos_ | hm, no | 09:46 |
| lkcl | markos_, no, it would need several clear days and a lot of persistence. it really isn't easy. | 09:46 |
| cesar | Not if the jumpers are in the USB position. | 09:46 |
| lkcl | yes following a path that has been done before and is working is the key lesson here | 09:46 |
| lkcl | in the case of attempting to run ls2 on an unknown board, there are about *18* possible things that could have gone "wrong" | 09:47 |
| markos_ | cesar, ah yes, indeed, I need to move the jumper to QSPI to have it show the info in the oled screen | 09:47 |
| markos_ | if still in USB position, it will turn green and stay that way | 09:48 |
| lkcl | 1. clock rate too high. 2. PLL set up incorrectly 3. LED wire defined incorrectly (pin and voltage) 4. UART wire defined incorrectly (pin and voltage) ..... | 09:48 |
| markos_ | but I have no way of knowing what it does, nothing on serial (uart) | 09:48 |
| lkcl | then the first thing you need to do markos_ is is write an FPGA program that sets the serial pin "high" and *nothing* else | 09:48 |
| lkcl | not even from a clock (using nmigen "sync" domain) but just a combinatorial "set" of that pin | 09:49 |
| lkcl | then you will know the answer to the question "is the board definition file correct in regards to the uart pin" | 09:49 |
| markos_ | lkcl, I really wish I had more time to allocate to dedicate to this, but sadly I do not, not at this time anyway | 09:50 |
| lkcl | it's *that* level of basic checking of the massive chain, any one thing in which could prevent you from getting results | 09:50 |
| lkcl | markos_, i'm explaining it to you quite how fundamentally low-level this really is so that you have the right expectations | 09:50 |
| markos_ | I would prefer to just send this board to whomever is willing to do this work and just a get a known working onw | 09:50 |
| markos_ | s/onw/now | 09:51 |
| lkcl | cesar, you up for that? :) | 09:51 |
| lkcl | markos_, arty a7-100t. it's what we kinda standardised on as it's easy to get hold of | 09:52 |
| lkcl | and it is also one of the microwatt targets | 09:52 |
| markos_ | lkcl, I only have today to spare, tomorrow I'm resuming work on vectorscan which needs a lot of attention as well | 09:52 |
| markos_ | yeah, that one will do, I expected this to be much easier since it's supposedly in the supported list and it's in the same family of fpga chips | 09:53 |
| lkcl | another lesson learned there, i feel, that these things take one hell of a lot of sustained focus. | 09:53 |
| lkcl | naah. i was at the time willing to do it because i knew what would be involved. now i simply can't - it's been too much | 09:54 |
| markos_ | I wouldn't mind doing it if I had more time, but right now is not a good time for me to start yet another project, as I said I'm already close to a burnout juggling more than 5 -full-time- projects | 09:54 |
| markos_ | and I can't seem to be able to find good coders, the juniors require way too much training that I just cannot afford to do, no time, the seniors who know their stuff require too much money, which I also cannot afford at the moment | 09:55 |
| markos_ | it's a vicious cycle | 09:55 |
| markos_ | interviewing university graduates seems to disappoint me even more, seems they don't teach C properly in the universities anymore and I'm constantly asking "wtf, how can you get a degree and not know basic C and Linux?" | 09:57 |
| markos_ | I'm not even talking about advanced topics | 09:57 |
| lkcl | markos_, we were not taught c at Imperial because the lecturers had seen too many of us be poached by Industry and not complete the degree | 09:59 |
| lkcl | instead we were taught the fundamentals that would allow us to learn pretty much anything | 10:00 |
| openpowerbot | [irc] <lkcl> programmerjake, can you please make sure that any bugreport that you create is linked to at least one other by "See also, depends or blocks" | 10:01 |
| markos_ | well, I didn't learn C myself at the university, but I was studying physics, they only taught us FORTRAN :D | 10:01 |
| openpowerbot | [irc] <lkcl> as a mandatory project requirement that should be done *immediately* as a matter of routine, so that i do not have to remind you | 10:01 |
| openpowerbot | [irc] <lkcl> i have reminded you many times, i need to stop reminding you and you to take on responsibility for proper project management for yourself | 10:02 |
| markos_ | but for a person doing CS/CE (esp the latter) I would consider entirely obvious that learning C/Linux should be one of the basic things to learn | 10:02 |
| openpowerbot | [irc] <lkcl> bugs that are isolated from the Group/Set (using math term) become extremely hard to find, as they are isolated and require "search" to track down, forcing people to do far more work | 10:03 |
| markos_ | I mean, how they hell can you teach OS design and implementation without doing some examples in C? | 10:03 |
| cesar | markos_, no worries about SSH. | 10:04 |
| lkcl | markos_, it's the difference between education and training. | 10:04 |
| markos_ | s/they hell/the hell | 10:04 |
| markos_ | lkcl, yes, but in order to train someone you expect some basic knowledge | 10:05 |
| cesar | If sending the board to me, I'd have to pay a hefty import tax. | 10:05 |
| lkcl | linux OS usage does not require "education" it requires *training*. "run this command, do this thing, it gets these results" | 10:05 |
| markos_ | cesar, not if I send it as gift | 10:05 |
| cesar | Ok, we can try that. | 10:06 |
| markos_ | I receive a lot of stuff from overseas (US/UK/China), tax is only applicable when there is an actual sale | 10:06 |
| lkcl | we were taught instead about how the George III Operating System worked, as a way to demonstrate one of the very first Virtual Memory systems | 10:06 |
| lkcl | (by one of the people whom i believe had actually worked on it) | 10:06 |
| markos_ | lkcl, I'm not talking about linux commands usage, but yes, basic things like how files are organized in the Linux FHS and why (what are block devices, what are char devices, etc) should be things in a university course, also for OS, what are interrupts, what are semaphores, spinlocks, etc etc | 10:07 |
| markos_ | these are *fundamental* OS concepts | 10:07 |
| lkcl | Andrew Tanenbaum taught OS basics to his students through minux - because it's so much simpler. | 10:07 |
| cesar | Well, maybe its different here (import tax over gifts). | 10:07 |
| markos_ | of course | 10:08 |
| markos_ | cesar, really? | 10:08 |
| markos_ | ok, I'll try to set up a system with ssh access connected to the nexys video | 10:08 |
| lkcl | i didn't get to spinlocks (didn't know what they were) until 2000, 12 years after i finished my degree. | 10:08 |
| markos_ | cesar, would you like me to set up the environment on this system or would you do it yourself? | 10:09 |
| lkcl | i also had no idea what block and char devices are, nor what FHS was. | 10:09 |
| lkcl | but i knew about interrupts and i think i had vaguely heard of semaphores | 10:09 |
| lkcl | the basics i had been *educated* in - not trained - *educated* - allowed me to absorb all of those concepts in my stride when i encountered them | 10:10 |
| markos_ | you're missing my point | 10:10 |
| lkcl | someone from the British Computing Society did a presentation about this, about 15 years ago | 10:11 |
| lkcl | he said he explains to parents the difference: | 10:11 |
| markos_ | it's the constant complaint many companies have, graduates are just not work-ready | 10:11 |
| lkcl | "if this were sex we were talking about, in this school, would you prefer that your child be given sex education or sex training?" | 10:11 |
| markos_ | hahaha, good one, but it's not the same thing | 10:12 |
| lkcl | it is indeed. | 10:12 |
| lkcl | anyone can look up "how to do X" by running a google search query | 10:12 |
| cesar | No hurry about SSH. How about I just send you bit files for you to flash into the USB drive, once in a while? | 10:12 |
| markos_ | cesar, yes please | 10:12 |
| lkcl | but yes if they don't *know* that that's even possible, then yes they're in trouble | 10:13 |
| markos_ | lkcl, no, knowledge is not acquired just by googling | 10:13 |
| markos_ | it's the fundamental difference between knowledge and information | 10:13 |
| lkcl | David tells the story about how he would select engineers, by giving them a PCB they'd never seen | 10:13 |
| markos_ | one you actually possess, the other you do not, big difference | 10:13 |
| lkcl | by the first few questions they asked, he knew whether he could train them or not | 10:14 |
| markos_ | indeed | 10:14 |
| lkcl | people such as you and i are auto-didacts (and also know our limitations) | 10:15 |
| lkcl | (what's practical within a set time and committment, and what isn't) | 10:15 |
| lkcl | and it's a whooole new level compared to most people in computing (new and old) | 10:17 |
| markos_ | indeed, hence the whole discussion, I know my limits and I know I cannot make this board work on my own in the short timeframe that I have :) | 10:17 |
| lkcl | :) | 10:17 |
| lkcl | awesome! progress! :) | 10:18 |
| markos_ | :D | 10:18 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-90-154-80-239.ip.moscow.rt.ru> has quit IRC | 10:27 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.10> has joined #libre-soc | 10:29 | |
| *** cesar <cesar!~cesar@2804:14d:688a:59ea:bd4e:1a53:81fb:ba0> has quit IRC | 11:40 | |
| *** cesar <cesar!~cesar@2804:14d:688a:59ea:b6dc:1926:357d:cf4> has joined #libre-soc | 11:42 | |
| cesar | markos_, can we try again, together? When convenient, try to repeat the steps, up to the green light. Nothing more. | 11:46 |
| markos_ | well, getting the green light works | 11:58 |
| markos_ | both jumpers to USB, usb stick in the usb port, usb cable to UART port (only ttyUSB0), BUSY led on for a few seconds and then green light appears | 11:59 |
| markos_ | but nothing on minicom | 11:59 |
| markos_ | usb stick has only proj/nexys_video_demo.runs/impl_1/system_wrapper.bit | 12:00 |
| cesar | Good. The OLED in not showing any messages, right? | 12:04 |
| markos_ | nothing at all | 12:06 |
| markos_ | not sure what this demo is supposed to do, I also don't get anything in the UART | 12:06 |
| cesar | No worries. Now, press the red PROG button next to JP4. | 12:07 |
| markos_ | ok, now BUSY led is on | 12:09 |
| cesar | How about the OLED? | 12:09 |
| markos_ | and then again it goes off and green led is on | 12:09 |
| markos_ | still nothing on it | 12:09 |
| cesar | Weird. Try pushing a button, see if some LED light up. | 12:10 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.10> has quit IRC | 12:10 | |
| markos_ | well, green light is on as I said | 12:11 |
| markos_ | if I switch the JP4 to QSPI then the oled will work as before | 12:11 |
| markos_ | I guess the default image in the QSPI flash is the demo | 12:12 |
| markos_ | with the oled info that | 12:12 |
| markos_ | that is | 12:12 |
| cesar | Indeed. | 12:12 |
| markos_ | the problem is getting the usb PROG functionality with xc3sprog or another program, if you could tell me what to look for and modify the code for it, I'd be happy to do it, but I just don't know where to start | 12:14 |
| markos_ | or even build the bitstream for the nexys_video and then try that bit file | 12:14 |
| markos_ | even with usb | 12:14 |
| cesar | From my understanding, that bit file, in the zip archive, was exactly the factory design, in bit file form. | 12:14 |
| cesar | So, it should have displayed messages in the OLED, not just the green LED. | 12:15 |
| markos_ | from the readme: This application is loaded from the QSPI flash by the bootloader. Upon warm-boot (reset with CPU_RESETN) the | 12:15 |
| markos_ | processor jumps to the reset vector. If the demo application is compiled normally, it populates the reset vector. This means that the processor is reset to the demo, not to the bootloader. Unfortunately the memory sections for | 12:15 |
| markos_ | demo are not re-initialized and contain the previous run's values. This will result in driver init failures and | 12:15 |
| markos_ | heap allocation errors. To fix this the reset vectors needs to point to the bootloader in BRAM. This requires | 12:15 |
| markos_ | the demo to be compiled with specific settings. See my forum post for solution: | 12:16 |
| markos_ | I guess it won't work with a simple upload? | 12:16 |
| markos_ | similarly, ls2/top.bit when copied to the USB stick just has the BUSY led flashing fast | 12:20 |
| cesar | Maybe it's stuck in the bootloader, yes. If so, I consider it a success. Means we can upload designs (even if made with Vivado) through USB for now. | 12:23 |
| markos_ | ok, let's try something else, how can I try blinky on the board? | 12:25 |
| cesar | About top.bit, you mean the one created with "nmigen_boards/nexys_video.py", right? If so, it's not ls2, the full core. It's just a Blinky. Just to get terminology right, | 12:26 |
| cesar | * "python3 nmigen_boards/nexys_video.py" | 12:27 |
| markos_ | no, it was the one generated in ls2 directory following Andrey's instructions | 12:28 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.65> has joined #libre-soc | 12:28 | |
| markos_ | https://pastebin.com/wrwNHetC | 12:29 |
| markos_ | I did install fasm however | 12:29 |
| markos_ | xc3sprog fails as expected, serial was connected to UART | 12:29 |
| cesar | It generated a bit file, however. Please try saving that "/tmp/nmigen_sjssw2ha_top.bit" to the USB drive, removing the other. | 12:31 |
| openpowerbot | [irc] <sadoon[m]1> Ok so ld.so still has all the VSX insns and co, but that's probably like programmerjake said, it'll only use them when they are needed | 12:31 |
| markos_ | cesar, it gets deleted | 12:32 |
| openpowerbot | [irc] <sadoon[m]1> Even the gentoo ld.so has it so I assume it's fine | 12:34 |
| cesar | Look in the "build" directory under your current directory. | 12:34 |
| cesar | ... for a top.bit. | 12:34 |
| cesar | ... with a recent timestamp. | 12:35 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.65> has quit IRC | 12:36 | |
| markos_ | ok, that one works | 12:36 |
| markos_ | but I don't see anything :) | 12:36 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-90-154-80-239.ip.moscow.rt.ru> has joined #libre-soc | 12:37 | |
| markos_ | it seems to program (BUSY led on) and then just gives a green led | 12:37 |
| markos_ | but nothing on serial | 12:37 |
| markos_ | I mean, it seems to have worked, but I'm not sure what it's supposed to do | 12:39 |
| cesar | This is a Blinky, it should blink all leds on the board (not just turn them on). | 12:39 |
| markos_ | nope, nothing happens | 12:39 |
| cesar | Now, try pressing the red PROG button next to JP4. | 12:39 |
| markos_ | same result | 12:40 |
| markos_ | green led on, nothing else happens | 12:40 |
| markos_ | cleaning up the build directory just in case there was a leftover file from before | 12:41 |
| markos_ | nope, removed build/ and reran python3 nmigen_boards/nexys_video.py, same result | 12:44 |
| markos_ | wait | 12:46 |
| markos_ | there are microswitches for each led, and they were all set to off | 12:46 |
| markos_ | ah no, still nothing when set to on | 12:47 |
| markos_ | sigh | 12:47 |
| cesar | No worries. | 12:47 |
| lkcl | sadoon: toshywoshy described when you weren't at tuesday's meeting that he had to do a backport of libc6. | 12:48 |
| lkcl | and that "latest" required a very simple compile-switch | 12:48 |
| lkcl | markos_, "python3 nmigen_boards/nexys_video --build" | 12:50 |
| lkcl | unless "program=True" has been set in the last line | 12:50 |
| lkcl | if you just want "build only" and "program=True" has been set, it should be obvious to change that to "program=False" then look in the build/ directory | 12:50 |
| markos_ | NexysVideoPlatform(toolchain="yosys_nextpnr").build(do_program=True) | 12:50 |
| lkcl | obvious what that means? | 12:51 |
| markos_ | yup | 12:51 |
| markos_ | do_program=True -> call xc3sprog else don't call it :) | 12:52 |
| lkcl | *when* it fails it has *NO* impact on the contents of the build/ directory | 12:52 |
| lkcl | actually, "call the abstracted-out 'build' script which in the case of the nexys_video platform *HAPPENS* to call xc3sprog"... yes | 12:52 |
| openpowerbot | [irc] <sadoon[m]1> openpowerbot: That's cool, will look into that then | 12:53 |
| lkcl | if you look at the derivation chain for NexysVideoPlatform, guess what it derives from? XilinxPlatform! | 12:53 |
| lkcl | and guess what VERSA_ECP5 and other ECP5 platform classes derive from? | 12:53 |
| lkcl | LatticePlatform! | 12:53 |
| markos_ | either my board is broken or something else is amiss here, no leds are flashing | 12:54 |
| lkcl | and guess what the program() function in LatticePlatform does? call the appropriate script for programming the ECP5! | 12:54 |
| lkcl | it's all very logical | 12:54 |
| markos_ | it /appears/ to program the fpga at least | 12:54 |
| markos_ | I'm looking at the blinky class now | 12:54 |
| lkcl | ok so this is why i said "do a combinatorial thing instead" | 12:54 |
| lkcl | because a combinatorial thing (no "m.d.sync) will hard-wire a line to HI (or LO) and it's done | 12:55 |
| lkcl | remember that all classes are abstracted-out. | 12:55 |
| lkcl | "platform" argument is completely separate from "the thing that *USES* the platform" | 12:56 |
| lkcl | otherwise just to do a "Blinky lights" test you have to write *one frickin test program per frickin board* | 12:56 |
| lkcl | which is total madness. | 12:56 |
| markos_ | yes, apparently digilent must have done something differently to the platform default here | 12:56 |
| lkcl | therefore the platform defines things like "a uart" | 12:56 |
| lkcl | that is highly unlikely given that the litex nexys_video platform python code is near-identical to the litex arty_a7 platform python board | 12:57 |
| markos_ | yes, yes, I understand the principles just fine, it's something like uboot, only scaled down (a lot!) | 12:57 |
| markos_ | I've done uboot development in the past | 12:57 |
| lkcl | by an order of magnitude, minimum, yes. | 12:57 |
| markos_ | so I need to basically put the expected values for the actual platform specs in order for abstractions to properly match what the board expects | 12:58 |
| lkcl | you have to think of eeevvverything, right down to "is the PLL programmed up with the correct settings which involves plugging in the correct *wires* to it not just the right *settings* like you have to in u-boot" | 12:58 |
| markos_ | which needs time, which I don't have :/ | 12:58 |
| lkcl | markos_, it's already been done - in litex. cesar simply copied and converted the litex platform file to nmigen platform file | 12:59 |
| markos_ | because I don't suppose it's going to be easy to do, unless it's a trivial 10-minute deal | 12:59 |
| lkcl | cesar, can you check to see if there are any differences in the setup of the PLL for nexys_video, in litex? | 13:00 |
| lkcl | i doubt it very much | 13:00 |
| markos_ | ok, I found this: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/digilent_nexys_video.py | 13:00 |
| lkcl | > <markos_> so I need to basically put the expected values | 13:00 |
| lkcl | no you don't: the *platform* file (nexys_video.py) defines them for you. | 13:00 |
| lkcl | but we are in the situation of having to be the first to do it | 13:01 |
| markos_ | well, yes, but someone has to put them in the file first that's what I mean :) | 13:01 |
| lkcl | now if you find the equivalent digilent_arty_a7.py platform file | 13:01 |
| markos_ | I seem that some values that cesar has already filled in | 13:01 |
| lkcl | and compare *that* to the nmigen arty_a7.py platform file | 13:01 |
| markos_ | but the litex has a lot more info in it | 13:01 |
| lkcl | then you have an "A is to B as C is to D" against which to check the (new) board file | 13:02 |
| cesar | lkcl_, sure, I'll check the PLL. As you say, better to try a combinatorial design first. | 13:02 |
| cesar | (just turn on a LED) | 13:03 |
| lkcl | cesar, or use a very-simple-modifed blinky.py which combinatorially turns on an LED, yes | 13:03 |
| lkcl | self.toolchain.additional_commands = \ | 13:04 |
| lkcl | ["write_cfgmem -force -format bin -interface spix4 -size 16 " | 13:04 |
| lkcl | those look like they're openocd commands to me | 13:04 |
| lkcl | or... urrrr they're vivado commands | 13:04 |
| * lkcl throws up | 13:04 | |
| lkcl | ignore them | 13:05 |
| * lkcl need to go for a walp | 13:05 | |
| lkcl | k | 13:05 |
| markos_ | but similar commands are on the arty_a7.py file | 13:05 |
| markos_ | though that one I see uses Symbiflow | 13:06 |
| markos_ | not yosys_nextpnr that nexys_video is calling | 13:06 |
| markos_ | could that be a problem? | 13:06 |
| cesar | I'll look into it. | 13:09 |
| markos_ | could you also add a UARTResource so that I can see some output on serial? | 13:11 |
| markos_ | I added it but I guess the pins are wrong :) | 13:12 |
| cesar | Like lkcl says, I think UART is a bit ahead of us right now. | 13:13 |
| markos_ | oh, I thought it was an easy thing :) | 13:14 |
| cesar | To see anything on serial, you need a UART HDL design, which is more complex that a blinking LED. | 13:14 |
| cesar | Well, at least a baud rate generator, and a shift register. Not that more complex. | 13:15 |
| markos_ | lunchtime bbl :) | 13:15 |
| markos_ | back | 13:40 |
| cesar | I'm wondering how to send you Python programs and bit files. | 14:06 |
| cesar | Maybe some FTP service. Not worth it to use Git for that. | 14:06 |
| markos_ | temporary git branch? | 14:07 |
| markos_ | that will be removed later? | 14:07 |
| markos_ | I mean they're not huge binary files | 14:07 |
| markos_ | it *is* for testing nexys_video enablement after all :) | 14:10 |
| cesar | Sure. You have my branch of nmigen-boards checked out already, we will use that then. | 14:14 |
| markos_ | yes | 14:14 |
| cesar | OK. I'll create a simple design (simpler than a Blinky) which will simply turn on one led. | 14:33 |
| cesar | Going for a walk, be back later. | 14:35 |
| *** cesar <cesar!~cesar@2804:14d:688a:59ea:b6dc:1926:357d:cf4> has quit IRC | 14:40 | |
| *** cesar <cesar!~cesar@2804:14d:688a:59ea:b6dc:1926:357d:cf4> has joined #libre-soc | 15:18 | |
| openpowerbot | [irc] <sadoon[m]1> toshywoshy do you remember the compile time options that disables vsx and co? | 15:24 |
| openpowerbot | [irc] <sadoon[m]1> for glibc* | 15:24 |
| openpowerbot | [irc] <sadoon[m]1> Weirdly I can see the gcc invokations during the build process actually using my custom flags so I assumed that would be enough | 15:25 |
| openpowerbot | [irc] <sadoon[m]1> # Stupid GCC requires us to pass all these ridiculous switches. We need to... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/EDUzBHkXSKLchSTvVLbkcQnx>) | 15:34 |
| openpowerbot | [irc] <sadoon[m]1> Even the glibc guys are frustrated | 15:34 |
| *** cesar <cesar!~cesar@2804:14d:688a:59ea:b6dc:1926:357d:cf4> has quit IRC | 15:50 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-90-154-80-239.ip.moscow.rt.ru> has quit IRC | 16:46 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-90-154-80-239.ip.moscow.rt.ru> has joined #libre-soc | 16:49 | |
| *** cesar <cesar!~cesar@2804:14d:688a:59ea:b6dc:1926:357d:cf4> has joined #libre-soc | 17:55 | |
| cesar | markos_, please try: | 18:56 |
| cesar | git pull | 18:56 |
| cesar | python3 nmigen_boards/test/nexys_video/led_on.py | 18:57 |
| markos_ | Warning: No clocks found in design | 19:10 |
| markos_ | flashing now | 19:11 |
| markos_ | sigh, same result, green light, no leds blinking | 19:11 |
| cesar | No worries. | 19:16 |
| cesar | This one should have turned on led LD0 (T14). No blinking. | 19:18 |
| cesar | For the record, the green light is labeled "DONE", right? | 19:21 |
| markos_ | yes | 19:29 |
| markos_ | tell you what, I will investigate further but now now, towards the end of the month, I can do some more reading on openocd, litex and what all these numbers and elements in the definitions of a board are and I can retry | 19:39 |
| markos_ | litex for comparison I mean | 19:39 |
| cesar | Well, my idea was to do exactly that, and tell you the commands to try... | 20:01 |
| cesar | markos_, I suggest to try: | 20:22 |
| cesar | openocd -f /usr/share/openocd/scripts/board/digilent_nexys_video.cfg -c "transport select jtag; init; exit" | 20:23 |
| cesar | actually, | 20:23 |
| cesar | openocd -f /usr/share/openocd/scripts/board/digilent_nexys_video.cfg -c "transport select jtag;init;pld load 0 build/top.bit;exit" | 20:23 |
| markos_ | ok this seems to work, it flashed the board, green led again | 22:04 |
| markos_ | but same result, no other blinking leds | 22:04 |
| cesar | Progress! For good measure, try with NexysVideo_User_Demo/proj/nexys_video_demo.runs/impl_1/system_wrapper.bit | 22:09 |
| cesar | I guess you can put jumper JP1 in the JTAG position. | 22:20 |
| markos_ | well, it programs ok, but nothing else | 22:23 |
| cesar | Where did you get openocd? | 22:25 |
| markos_ | ? | 22:25 |
| markos_ | I installed it on the host not the schroot if you're asking that, and copied the bit file there | 22:26 |
| cesar | How did you install openocd? I tried the Debian version, in the schroot, and it doesn't have the file /usr/share/openocd/scripts/board/digilent_nexys_video.cfg. | 22:27 |
| markos_ | yes that one is too old | 22:27 |
| markos_ | the one in the host works though | 22:27 |
| markos_ | bookworm version | 22:27 |
| cesar | I'll see about adding it to the fpga dev script (compiled from source). | 22:32 |
| *** cesar <cesar!~cesar@2804:14d:688a:59ea:b6dc:1926:357d:cf4> has quit IRC | 22:39 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 22:59 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!