| *** tpb has joined #timvideos | 00:00 | |
| *** sph6 has joined #timvideos | 00:12 | |
| *** sph6 has quit IRC | 00:14 | |
| *** Matombo0 has joined #timvideos | 00:49 | |
| shorne | CarlFK: yes, we should see the boot squence printk messages, they are written to the main console | 00:54 |
|---|---|---|
| shorne | cr1901_modern: great, if you have any gcc questions let me know | 00:54 |
| CarlFK | shorne: sounds like a simple fix ;) | 00:55 |
| CarlFK | jk- I can't imagine anything VM being simple | 00:56 |
| cr1901_modern | shorne: Actually I do unfortunately. But not for or1k, but rather for lm32 | 00:57 |
| cr1901_modern | are you still willing to help? | 00:57 |
| shorne | cr1901_modern: sure, the guys one OFTC/#gcc are very helpful for gcc questions too | 01:00 |
| shorne | please let me know | 01:00 |
| cr1901_modern | shorne: I have an example ready right now | 01:00 |
| shorne | ok | 01:01 |
| cr1901_modern | shorne: http://ix.io/1nH0 | 01:02 |
| cr1901_modern | In this code, gcc decides the best way to get to the value of .LC0 is to load .LC1 and then do a load-word. | 01:03 |
| cr1901_modern | Why would code like this be generated instead of directly loading the value of .LC0? | 01:03 |
| *** ninov has joined #timvideos | 01:04 | |
| *** ninov has quit IRC | 01:06 | |
| shorne | cr1901_modern: looking, what optimization level are you using -O0? | 01:06 |
| shorne | I see | 01:07 |
| shorne | -O3 | 01:07 |
| cr1901_modern | shorne: Context if you're interested: https://twitter.com/cr1901/status/1045419756763979776 | 01:08 |
| cr1901_modern | We've been talking about constant pools and constant generation all day in #j-core, trying to beat it into my head | 01:08 |
| shorne | I see, its a bit strange let me just try with my compiler | 01:12 |
| shorne | cr1901_modern: https://gist.github.com/16222a6b989e040962b24140ed5fd70e | 01:13 |
| tpb | Title: put.s · GitHub (at gist.github.com) | 01:13 |
| shorne | no issue there | 01:14 |
| cr1901_modern | right or1k does the right thing | 01:14 |
| cr1901_modern | (yay a delay slot actually used for once) | 01:14 |
| shorne | cr1901_modern: yes, it generates better code than I could do (most of the time :)) | 01:15 |
| shorne | there are a few optimizations left to do... but want to get upstream first | 01:15 |
| shorne | let me look at the lm32 port | 01:15 |
| shorne | it might be something with how the mov* pattern is implemented | 01:16 |
| shorne | but its also just strange that it defines the .LC1 reference in the first place | 01:17 |
| cr1901_modern | shorne: Tyvm, this makes me feel a lot better | 01:20 |
| *** mute14 has joined #timvideos | 01:21 | |
| *** rkratky has joined #timvideos | 01:22 | |
| *** mute14 has quit IRC | 01:25 | |
| shorne | cr1901_modern: notice strings are in '.rodata.str*' section the pointers are in '.rodata.cst*' | 01:26 |
| cr1901_modern | shorne: I did _not_ notice this :). | 01:26 |
| cr1901_modern | I have no idea what this means, but it indicates it's a deliberate decision | 01:26 |
| *** asdfguy20 has joined #timvideos | 01:27 | |
| *** rkratky has quit IRC | 01:27 | |
| *** asdfguy20 has quit IRC | 01:30 | |
| shorne | Yeah, also I see lm32 defines this small data thing... | 01:35 |
| shorne | https://github.com/stffrdhrn/gcc/blob/or1k-port/gcc/config/lm32/lm32.c#L792-L819 | 01:35 |
| tpb | Title: gcc/lm32.c at or1k-port · stffrdhrn/gcc · GitHub (at github.com) | 01:35 |
| shorne | I am not quite sure, but it might mean it stores data and var references in seprate sections? | 01:36 |
| shorne | .rodata.cst - is for constants | 01:38 |
| shorne | cr1901_modern: I looked through the lm32 port, those are the things that stood out. There might be a reason for it, but I cant see why right now. | 01:55 |
| cr1901_modern | shorne: Sorry for the delay, thanks for taking a look | 01:56 |
| cr1901_modern | Maybe I'll contact lattice | 01:57 |
| *** sb0 has quit IRC | 01:58 | |
| shorne | checking in the #gcc room on the OFTC server doesnt hurt | 02:01 |
| shorne | or just sending gcc an email | 02:01 |
| *** Alternity28 has joined #timvideos | 02:01 | |
| shorne | or raise a bug | 02:01 |
| cr1901_modern | shorne: I think I will do that, or at least stop in. Unfortunately tonight I'm really getting my ass kicked in #j-core re: constants and PIC and crap | 02:03 |
| *** Alternity28 has quit IRC | 02:04 | |
| shorne | CarlFK: one thing | 02:04 |
| shorne | build/arty_net_or1k.linux/software/include/generated/csr.h:#define CSR_UART_BASE 0xe0001800 | 02:04 |
| shorne | third_party/linux/include/dt-bindings/litex.h:#define CSR_UART_BASE 0xe0001000 | 02:05 |
| shorne | there is a sifference in the location of UAT between linux and qemu | 02:07 |
| shorne | UART* that would be the first problem | 02:07 |
| shorne | Lets see what else | 02:08 |
| shorne | Ill also check if maybe devicetree generation woths | 02:08 |
| shorne | works* | 02:08 |
| *** tosky has joined #timvideos | 02:21 | |
| *** tosky has quit IRC | 02:25 | |
| *** kseniya201626 has joined #timvideos | 02:27 | |
| shorne | mithro: Hi tim, I see during ./script/build-linux.sh you check out litex-devicetree, but I dont see it being used | 02:29 |
| shorne | I tried to use it an it seems to have some bugs | 02:29 |
| shorne | any comment on the current state of it? | 02:30 |
| shorne | I will try to manually update the or1klitex.dts for the moment | 02:30 |
| *** kseniya201626 has quit IRC | 02:31 | |
| cr1901_modern | shorne: There is one more q I have re: gcc, but doesn't need to be tonight. Does or1k use constant pools AND have a mvhi/mvlo idiom? | 02:42 |
| CarlFK | shorne: I expect mithro is asleep right now - 3am ish | 02:44 |
| shorne | CarlFK: we dont use constant pools, we have a GOT when specifying fPIC which is kind of similar | 02:47 |
| cr1901_modern | I don't see how a GOT is similar to a constant pool, but my mind is kinda friend tonight | 02:48 |
| shorne | we have the same mvhi/mvlo, we do 'l.movhi r2, hi(symbol)' 'l.ori r2, r2, lo(symbol)' or 'l.addi ...' | 02:48 |
| shorne | cr1901_modern: well, before right now I never really heard of a constant pool, I read this http://benno.id.au/blog/2009/01/02/literal-pools | 02:49 |
| tpb | Title: The trouble with literal pools (at benno.id.au) | 02:49 |
| shorne | it says literal pool, maybe completely different | 02:49 |
| cr1901_modern | it's using pc-relative addressing to access a constant value stored in the binary. It uses one less insn than mvi/mvlo | 02:50 |
| shorne | yeah | 02:51 |
| cr1901_modern | Ultimately, they both require the same amount of bytes tho; constant pools just move one of those 32-bit words to the data cache | 02:52 |
| cr1901_modern | what I was confused about is MIPS seems to use both mvhi/mvlo idiom and a constant pool to generate constants: sorear: GOT is needed *for code in shared libraries* because it's the only way to make interposition work | 02:52 |
| cr1901_modern | err sorry, ignore that, paste fail | 02:52 |
| cr1901_modern | https://github.com/gcc-mirror/gcc/blob/master/gcc/config/mips/mips.c#L4135-L4179 | 02:52 |
| tpb | Title: gcc/mips.c at master · gcc-mirror/gcc · GitHub (at github.com) | 02:52 |
| cr1901_modern | Naturally I don't understand it, maybe someone who works on GCC has a better idea on how the MIPS backend decides which constant generation scheme to use | 02:53 |
| shorne | cr1901_modern: it seems gcc likes to use constant/linteral pools by default | 03:06 |
| shorne | I see in openrisc we set this | 03:06 |
| shorne | https://github.com/stffrdhrn/gcc/blob/or1k-port/gcc/config/or1k/or1k.c#L851-L864 | 03:06 |
| tpb | Title: gcc/or1k.c at or1k-port · stffrdhrn/gcc · GitHub (at github.com) | 03:06 |
| shorne | (the comment says don't allow to use literal pool) | 03:07 |
| *** aze12 has joined #timvideos | 03:17 | |
| *** aze12 has quit IRC | 03:26 | |
| *** Anrky11 has joined #timvideos | 03:26 | |
| *** Maescool22 has joined #timvideos | 03:34 | |
| *** rohitksingh_work has joined #timvideos | 03:49 | |
| *** rohitksingh_wor1 has joined #timvideos | 04:14 | |
| *** rohitksingh_work has quit IRC | 04:15 | |
| *** hyadez has quit IRC | 04:49 | |
| *** rohitksingh_work has joined #timvideos | 04:52 | |
| *** rohitksingh_wor1 has quit IRC | 04:53 | |
| *** hyadez has joined #timvideos | 05:02 | |
| *** crankshaft_ has joined #timvideos | 05:44 | |
| *** crankshaft has quit IRC | 05:48 | |
| mithro | Just heading to the airport to go back to the US | 05:49 |
| *** peacefultom13 has joined #timvideos | 06:06 | |
| *** peacefultom13 has quit IRC | 06:10 | |
| *** sb0 has joined #timvideos | 06:12 | |
| *** toxync2121 has joined #timvideos | 06:33 | |
| *** Hazelesque10 has joined #timvideos | 06:33 | |
| *** toxync2121 has quit IRC | 06:35 | |
| *** iamdevnul3 has joined #timvideos | 07:09 | |
| *** iamdevnul3 has quit IRC | 07:11 | |
| *** jbmorris28911 has joined #timvideos | 07:24 | |
| *** jbmorris28911 has quit IRC | 07:27 | |
| shorne | CarlFK: spent some time tracing the kernel boot, it seems to not be running, it has failed during boot. What I thought was running was just a delay loop, not idle loop | 07:30 |
| *** brosef has joined #timvideos | 07:33 | |
| *** brosef has quit IRC | 07:37 | |
| xobs | shorne: Have you tried attaching a debugger? | 07:53 |
| xobs | ...using qemu | 07:54 |
| *** Vaivars0 has joined #timvideos | 07:58 | |
| *** Vaivars0 has quit IRC | 08:00 | |
| *** sagebind29 has joined #timvideos | 08:06 | |
| *** sagebind29 has quit IRC | 08:08 | |
| *** mza17 has joined #timvideos | 08:11 | |
| *** mza17 has quit IRC | 08:13 | |
| shorne | xobs: yes, and I can trace it | 08:22 |
| shorne | but.. I cant read memory for some reason I get | 08:22 |
| shorne | .. Cannot access memory at address 0xc0452930 | 08:23 |
| shorne | but maybe thats because everyting has crashed let me try to put a breakpoint before it crashes | 08:24 |
| shorne | no... I can set breakpoints but still cant read memory | 08:25 |
| shorne | something wrong with qemu/gdb | 08:25 |
| *** pmezard22 has joined #timvideos | 08:26 | |
| shorne | hmm, It looks like I can read memory when mmu is disabled | 08:27 |
| *** pmezard22 has quit IRC | 08:27 | |
| *** S0me0ne- has joined #timvideos | 08:29 | |
| *** S0me0ne- has quit IRC | 08:33 | |
| *** HeTo8 has joined #timvideos | 08:42 | |
| *** lipvig20 has joined #timvideos | 08:44 | |
| *** stefanotorresi18 has joined #timvideos | 08:45 | |
| *** stefanotorresi18 has quit IRC | 08:45 | |
| *** HeTo8 has quit IRC | 08:46 | |
| *** lipvig20 has quit IRC | 08:46 | |
| *** TheAMM10 has joined #timvideos | 09:09 | |
| *** TheAMM10 has quit IRC | 09:10 | |
| *** applegal21 has joined #timvideos | 09:19 | |
| *** applegal21 has quit IRC | 09:21 | |
| *** mf|cloud12 has joined #timvideos | 09:24 | |
| shorne | ok, was able to hack out a log | 09:26 |
| shorne | [ 0.000000] Kernel command line: earlycon | 09:26 |
| shorne | [ 0.000000] BUG: failure at /home/shorne/work/litex/litex-buildenv/third_party/linux/lib/ioremap.c:166/ioremap_page_range()! | 09:26 |
| shorne | [ 0.000000] Kernel panic - not syncing: BUG! | 09:26 |
| shorne | thats just the end | 09:26 |
| mithro | riscv32-unknown-elf-ld: boot-helper-vexriscv.o: can't link hard-float modules with soft-float modules | 09:28 |
| mithro | riscv32-unknown-elf-ld: failed to merge target specific data of file boot-helper-vexriscv.o | 09:28 |
| *** x0d16 has joined #timvideos | 09:28 | |
| *** mf|cloud12 has quit IRC | 09:29 | |
| *** iamayam7 has joined #timvideos | 09:30 | |
| *** x0d16 has quit IRC | 09:31 | |
| mithro | shorne: Did you see xobs' comments? | 09:32 |
| shorne | mithro: about debugger? yes | 09:32 |
| shorne | I am using the debugger to look at this | 09:32 |
| *** iamayam7 has quit IRC | 09:32 | |
| mithro | shorne: about the wrong spi flash version stuff? | 09:32 |
| shorne | no | 09:33 |
| shorne | but got to go now | 09:33 |
| mithro | xobs: I did have to set JOBS=1 to compile qemu, and I have to manually run qemu with "-global litex_ssi.spiflash=m25p80" (instead of the default of m25p16), and it doesn't load the firmware by default, but I can connect to it via gdb, run "load firmware.elf", then "mon system_reset", and I get a MicroPython prompt. | 09:34 |
| mithro | https://logs.timvideos.us/%23timvideos/%23timvideos.2018-09-26.log.html#t2018-09-26T15:23:25 | 09:34 |
| *** CarlFK has quit IRC | 09:35 | |
| mithro | build/arty_net_vexriscv/software/firmware/boot-helper-vexriscv.o: ELF 32-bit LSB relocatable, UCB RISC-V, version 1 (SYSV), not stripped | 09:40 |
| *** miip24 has joined #timvideos | 09:44 | |
| *** miip24 has quit IRC | 09:46 | |
| mithro | the BIOS seems to compile fine | 09:48 |
| mithro | Any idea how to figure out which module has the hard-float modules | 09:48 |
| mithro | ? | 09:48 |
| *** AJaeger0 has joined #timvideos | 09:49 | |
| xobs | mithro: If it's anything like ARM, "readelf -a" should tell you... somewhere | 09:49 |
| *** AJaeger0 has quit IRC | 09:49 | |
| mithro | Hrm... It seems the compile of the assemble boot helper file | 09:49 |
| mithro | riscv32-unknown-elf-gcc -std=gnu99 -c -MD -MP -Os -D__vexriscv__ -march=rv32im -mabi=ilp32 -g3 -fomit-frame-pointer -Wall -fno-builtin -nostdinc -I/home/tansell/github/timvideos/HDMI2USB-litex-firmware/third_party/litex/litex/soc/software/include/base -I/home/tansell/github/timvideos/HDMI2USB-litex-firmware/third_party/litex/litex/soc/software/include | 09:51 |
| mithro | -I/home/tansell/github/timvideos/HDMI2USB-litex-firmware/third_party/litex/litex/soc/common -I/home/tansell/github/timvideos/HDMI2USB-litex-firmware/build/arty_net_vexriscv/software/include -fexceptions -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -DTFTP_SERVER_PORT=6069 -o boot-helper-vexriscv.o | 09:51 |
| mithro | /home/tansell/github/timvideos/HDMI2USB-litex-firmware/third_party/litex/litex/soc/software/bios/boot-helper-vexriscv.S | 09:51 |
| mithro | compared too | 09:51 |
| mithro | riscv32-unknown-elf-gcc -std=gnu99 -c -o boot-helper-vexriscv.o boot-helper-vexriscv.S | 09:51 |
| xobs | mithro: use -mabi=ilp32d or ilp32f? | 09:56 |
| xobs | Or specify ilp32 for the rest of the files, to force soft-float | 09:57 |
| mithro | I'm very confused about the assembly line dropping the CFLAGS | 09:57 |
| xobs | Is it a different variable such as ASFLAGS? | 09:58 |
| mithro | Looks like an issue with implicit rules... | 10:05 |
| mithro | https://github.com/timvideos/litex-buildenv/commit/e1afe96 | 10:06 |
| tpb | Title: firmware: Add manual assembly for boot-helper file. · timvideos/litex-buildenv@e1afe96 · GitHub (at github.com) | 10:06 |
| auscompgeek | if you're using implicit rules, yeah, you'd want to set ASFLAGS as well | 10:06 |
| auscompgeek | see make's info(1) page about implicit variables | 10:06 |
| *** mishehu8 has joined #timvideos | 10:25 | |
| *** dshin10 has joined #timvideos | 10:25 | |
| *** mishehu8 has quit IRC | 10:26 | |
| *** netg2 has joined #timvideos | 10:28 | |
| mithro | WOOT! -> https://travis-ci.org/mithro/litex-buildenv/jobs/434540576 | 10:41 |
| mithro | The following builds succeeded | 10:42 |
| mithro | ============================================= | 10:42 |
| mithro | arty base vexriscv | 10:42 |
| mithro | arty net vexriscv | 10:42 |
| xobs | As it says: \o/ | 10:42 |
| xobs | Grats | 10:42 |
| mithro | LD firmware.elf | 10:47 |
| mithro | riscv32-unknown-elf-ld: firmware.elf section `.bss' will not fit in region `sram' | 10:47 |
| mithro | riscv32-unknown-elf-ld: region `sram' overflowed by 720 bytes | 10:47 |
| mithro | Wonder if it will build -> https://travis-ci.org/mithro/litex-buildenv | 11:03 |
| *** DeMiNe0_ has joined #timvideos | 11:12 | |
| *** DeMiNe0_ has quit IRC | 11:14 | |
| *** CarlFK has joined #timvideos | 11:44 | |
| *** ChanServ sets mode: +v CarlFK | 11:44 | |
| *** tsglove has quit IRC | 11:58 | |
| *** tsglove has joined #timvideos | 12:03 | |
| *** uriah3 has joined #timvideos | 12:20 | |
| *** uriah3 has quit IRC | 12:24 | |
| *** rohitksingh_work has quit IRC | 12:43 | |
| *** Kripton has quit IRC | 13:00 | |
| *** Kripton has joined #timvideos | 13:04 | |
| *** Otyg7 has joined #timvideos | 13:07 | |
| *** rohitksingh has joined #timvideos | 13:21 | |
| cr1901_modern | Just put .bss into main_ram? | 13:54 |
| cr1901_modern | I've done it before for the xmodem stuff- it doesn't harm anything | 13:54 |
| *** Airwave25 has joined #timvideos | 13:55 | |
| *** rohitksingh has quit IRC | 14:28 | |
| *** rohitksingh has joined #timvideos | 14:41 | |
| *** mgor_ has joined #timvideos | 14:52 | |
| *** mgor_ has quit IRC | 14:55 | |
| *** hermann_nordung has joined #timvideos | 15:15 | |
| *** hermann_nordung has quit IRC | 15:17 | |
| *** Guest99579 has joined #timvideos | 15:29 | |
| *** Guest99579 has quit IRC | 15:34 | |
| *** rohitksingh has quit IRC | 16:45 | |
| *** wolfshappen12 has joined #timvideos | 17:32 | |
| *** wolfshappen12 has quit IRC | 17:37 | |
| *** TecKnow has joined #timvideos | 18:05 | |
| *** TecKnow has joined #timvideos | 18:09 | |
| TecKnow | This is David from PS1 looking for Carl. I hope I'm in the right place. | 18:10 |
| CarlFK | you are! | 18:12 |
| CarlFK | excelt I am runiing out the door | 18:12 |
| CarlFK | and.. Tim's flight got canceled, so he wont' be to PS1 till about 4pm tomrrow :( | 18:12 |
| CarlFK | TecKnow: I'll be in a few wating rooms in the next hour or to, can get back to you on and off | 18:13 |
| *** CarlFK has quit IRC | 18:13 | |
| *** puck_ has quit IRC | 18:45 | |
| *** puck_ has joined #timvideos | 18:47 | |
| *** persia25 has joined #timvideos | 19:38 | |
| *** persia25 has quit IRC | 19:41 | |
| *** TinyTimmyTokyo0 has joined #timvideos | 19:49 | |
| *** TinyTimmyTokyo0 has quit IRC | 19:51 | |
| *** prg31810 has joined #timvideos | 20:04 | |
| *** prg31810 has quit IRC | 20:15 | |
| *** TecKnow has quit IRC | 20:47 | |
| *** CarlFK has joined #timvideos | 20:49 | |
| *** ChanServ sets mode: +v CarlFK | 20:49 | |
| CarlFK | im back for the day | 20:54 |
| *** MrNr1 has joined #timvideos | 20:55 | |
| TheAssassin | question: | 21:08 |
| TheAssassin | ever thought about using some (proprietary) HDMI receiver chip to provide cheap capturing? | 21:08 |
| TheAssassin | e.g., IT6604E | 21:08 |
| TheAssassin | these chips are just a couple of dollars in china, and even decrypt HDCP | 21:09 |
| TheAssassin | you'd just need a high-performance USB "gateway" thingy providing a raw or even encoded stream over USB | 21:09 |
| TheAssassin | sure, they're SMD chips, so you'd need some sorta "custom SMD PCB", but that'd be possible, I guess | 21:10 |
| CarlFK | I can see this going two ways: | 21:11 |
| CarlFK | 1. IT6604E does a better job than what we are currently doing with the fpga, so lets us do higher res/framrate - good. | 21:17 |
| CarlFK | 2. IT6604E replicates what we are doing with fpga, but we still need the fpga for other stuff, so all we have done is add complexity for no gain | 21:18 |
| CarlFK | Im thinking the R&D to prototype it will be 'hard' | 21:27 |
| TheAssassin | well, I just thought one could use such "standard chips" like that one to save some work and especially a lot of money | 21:47 |
| TheAssassin | this chip is used in really cheap HDMI equipment such as these "range extenders" which are in fact just creating a livestream | 21:47 |
| TheAssassin | they just add a hw encoder (h.264 or MJPEG) and some magic and it just works | 21:48 |
| TheAssassin | I know it wouldn't be fully open source, but perhaps could result in a better price point | 21:48 |
| TheAssassin | >300 USD for the hardware you guys designed, that's damn expensive | 21:49 |
| TheAssassin | is the problem to get some USB3 hw that interfaces with the chip and the USB host providing enough bandwidth? | 21:51 |
| TheAssassin | for e.g., the VOC, USB is not an option most likely, due to the limits of the USB hosts (you'd probably need one per input) | 21:52 |
| TheAssassin | but for testing a USB board would be great | 21:52 |
| *** anairo has joined #timvideos | 22:11 | |
| *** anairo has quit IRC | 22:12 | |
| CarlFK | I suspect one problem is finding a dev board like the Atlys | 22:16 |
| *** fitzsim has quit IRC | 22:57 | |
| *** royal_screwup213 has joined #timvideos | 23:51 | |
| *** Kripton has quit IRC | 23:52 | |
| *** royal_screwup213 has quit IRC | 23:55 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!