Friday, 2018-09-28

*** tpb has joined #timvideos00:00
*** sph6 has joined #timvideos00:12
*** sph6 has quit IRC00:14
*** Matombo0 has joined #timvideos00:49
shorneCarlFK: yes, we should see the boot squence printk messages, they are written to the main console00:54
shornecr1901_modern: great, if you have any gcc questions let me know00:54
CarlFKshorne: sounds like a simple fix ;)00:55
CarlFKjk- I can't imagine anything VM being simple00:56
cr1901_modernshorne: Actually I do unfortunately. But not for or1k, but rather for lm3200:57
cr1901_modernare you still willing to help?00:57
shornecr1901_modern: sure, the guys one OFTC/#gcc are very helpful for gcc questions too01:00
shorneplease let me know01:00
cr1901_modernshorne: I have an example ready right now01:00
cr1901_modernIn 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_modernWhy would code like this be generated instead of directly loading the value of .LC0?01:03
*** ninov has joined #timvideos01:04
*** ninov has quit IRC01:06
shornecr1901_modern: looking, what optimization level are you using -O0?01:06
shorneI see01:07
cr1901_modernshorne: Context if you're interested:
cr1901_modernWe've been talking about constant pools and constant generation all day in #j-core, trying to beat it into my head01:08
shorneI see, its a bit strange let me just try with my compiler01:12
tpbTitle: put.s · GitHub (at
shorneno issue there01:14
cr1901_modernright or1k does the right thing01:14
cr1901_modern(yay a delay slot actually used for once)01:14
shornecr1901_modern: yes, it generates better code than I could do (most of the time :))01:15
shornethere are a few optimizations left to do... but want to get upstream first01:15
shornelet me look at the lm32 port01:15
shorneit might be something with how the mov* pattern is implemented01:16
shornebut its also just strange that it defines the .LC1 reference in the first place01:17
cr1901_modernshorne: Tyvm, this makes me feel a lot better01:20
*** mute14 has joined #timvideos01:21
*** rkratky has joined #timvideos01:22
*** mute14 has quit IRC01:25
shornecr1901_modern: notice strings are in '.rodata.str*' section the pointers are in '.rodata.cst*'01:26
cr1901_modernshorne: I did _not_ notice this :).01:26
cr1901_modernI have no idea what this means, but it indicates it's a deliberate decision01:26
*** asdfguy20 has joined #timvideos01:27
*** rkratky has quit IRC01:27
*** asdfguy20 has quit IRC01:30
shorneYeah, also I see lm32 defines this small data thing...01:35
tpbTitle: gcc/lm32.c at or1k-port · stffrdhrn/gcc · GitHub (at
shorneI am not quite sure, but it might mean it stores data and var references in seprate sections?01:36
shorne.rodata.cst - is for constants01:38
shornecr1901_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_modernshorne: Sorry for the delay, thanks for taking a look01:56
cr1901_modernMaybe I'll contact lattice01:57
*** sb0 has quit IRC01:58
shornechecking in the #gcc room on the OFTC server doesnt hurt02:01
shorneor just sending gcc an email02:01
*** Alternity28 has joined #timvideos02:01
shorneor raise a bug02:01
cr1901_modernshorne: 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 crap02:03
*** Alternity28 has quit IRC02:04
shorneCarlFK: one thing02:04
shornebuild/arty_net_or1k.linux/software/include/generated/csr.h:#define CSR_UART_BASE 0xe000180002:04
shornethird_party/linux/include/dt-bindings/litex.h:#define CSR_UART_BASE 0xe000100002:05
shornethere is a sifference in the location of UAT between linux and qemu02:07
shorneUART* that would be the first problem02:07
shorneLets see what else02:08
shorneIll also check if maybe devicetree generation woths02:08
*** tosky has joined #timvideos02:21
*** tosky has quit IRC02:25
*** kseniya201626 has joined #timvideos02:27
shornemithro: Hi tim, I see during ./script/ you check out litex-devicetree, but I dont see it being used02:29
shorneI tried to use it an it seems to have some bugs02:29
shorneany comment on the current state of it?02:30
shorneI will try to manually update the or1klitex.dts for the moment02:30
*** kseniya201626 has quit IRC02:31
cr1901_modernshorne: 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
CarlFKshorne: I expect mithro is asleep right now - 3am ish02:44
shorneCarlFK: we dont use constant pools, we have a GOT when specifying fPIC which is kind of similar02:47
cr1901_modernI don't see how a GOT is similar to a constant pool, but my mind is kinda friend tonight02:48
shornewe have the same mvhi/mvlo, we do 'l.movhi r2, hi(symbol)' 'l.ori r2, r2, lo(symbol)' or 'l.addi ...'02:48
shornecr1901_modern: well, before right now I never really heard of a constant pool, I read this
tpbTitle: The trouble with literal pools (at
shorneit says literal pool, maybe completely different02:49
cr1901_modernit's using pc-relative addressing to access a constant value stored in the binary. It uses one less insn than mvi/mvlo02:50
cr1901_modernUltimately, they both require the same amount of bytes tho; constant pools just move one of those 32-bit words to the data cache02:52
cr1901_modernwhat 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 work02:52
cr1901_modernerr sorry, ignore that, paste fail02:52
tpbTitle: gcc/mips.c at master · gcc-mirror/gcc · GitHub (at
cr1901_modernNaturally 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 use02:53
shornecr1901_modern: it seems gcc likes to use constant/linteral pools by default03:06
shorneI see in openrisc we set this03:06
tpbTitle: gcc/or1k.c at or1k-port · stffrdhrn/gcc · GitHub (at
shorne(the comment says don't allow to use literal pool)03:07
*** aze12 has joined #timvideos03:17
*** aze12 has quit IRC03:26
*** Anrky11 has joined #timvideos03:26
*** Maescool22 has joined #timvideos03:34
*** rohitksingh_work has joined #timvideos03:49
*** rohitksingh_wor1 has joined #timvideos04:14
*** rohitksingh_work has quit IRC04:15
*** hyadez has quit IRC04:49
*** rohitksingh_work has joined #timvideos04:52
*** rohitksingh_wor1 has quit IRC04:53
*** hyadez has joined #timvideos05:02
*** crankshaft_ has joined #timvideos05:44
*** crankshaft has quit IRC05:48
mithroJust heading to the airport to go back to the US05:49
*** peacefultom13 has joined #timvideos06:06
*** peacefultom13 has quit IRC06:10
*** sb0 has joined #timvideos06:12
*** toxync2121 has joined #timvideos06:33
*** Hazelesque10 has joined #timvideos06:33
*** toxync2121 has quit IRC06:35
*** iamdevnul3 has joined #timvideos07:09
*** iamdevnul3 has quit IRC07:11
*** jbmorris28911 has joined #timvideos07:24
*** jbmorris28911 has quit IRC07:27
shorneCarlFK: 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 loop07:30
*** brosef has joined #timvideos07:33
*** brosef has quit IRC07:37
xobsshorne: Have you tried attaching a debugger?07:53
xobs...using qemu07:54
*** Vaivars0 has joined #timvideos07:58
*** Vaivars0 has quit IRC08:00
*** sagebind29 has joined #timvideos08:06
*** sagebind29 has quit IRC08:08
*** mza17 has joined #timvideos08:11
*** mza17 has quit IRC08:13
shornexobs: yes, and I can trace it08:22
shornebut.. I cant read memory for some reason I get08:22
shorne.. Cannot access memory at address 0xc045293008:23
shornebut maybe thats because everyting has crashed let me try to put a breakpoint before it crashes08:24
shorneno... I can set breakpoints but still cant read memory08:25
shornesomething wrong with qemu/gdb08:25
*** pmezard22 has joined #timvideos08:26
shornehmm, It looks like I can read memory when mmu is disabled08:27
*** pmezard22 has quit IRC08:27
*** S0me0ne- has joined #timvideos08:29
*** S0me0ne- has quit IRC08:33
*** HeTo8 has joined #timvideos08:42
*** lipvig20 has joined #timvideos08:44
*** stefanotorresi18 has joined #timvideos08:45
*** stefanotorresi18 has quit IRC08:45
*** HeTo8 has quit IRC08:46
*** lipvig20 has quit IRC08:46
*** TheAMM10 has joined #timvideos09:09
*** TheAMM10 has quit IRC09:10
*** applegal21 has joined #timvideos09:19
*** applegal21 has quit IRC09:21
*** mf|cloud12 has joined #timvideos09:24
shorneok, was able to hack out a log09:26
shorne[    0.000000] Kernel command line: earlycon09: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
shornethats just the end09:26
mithroriscv32-unknown-elf-ld: boot-helper-vexriscv.o: can't link hard-float modules with soft-float modules09:28
mithroriscv32-unknown-elf-ld: failed to merge target specific data of file boot-helper-vexriscv.o09:28
*** x0d16 has joined #timvideos09:28
*** mf|cloud12 has quit IRC09:29
*** iamayam7 has joined #timvideos09:30
*** x0d16 has quit IRC09:31
mithroshorne: Did you see xobs' comments?09:32
shornemithro: about debugger? yes09:32
shorneI am using the debugger to look at this09:32
*** iamayam7 has quit IRC09:32
mithroshorne: about the wrong spi flash version stuff?09:32
shornebut got to go now09:33
mithroxobs: 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
*** CarlFK has quit IRC09:35
mithrobuild/arty_net_vexriscv/software/firmware/boot-helper-vexriscv.o: ELF 32-bit LSB relocatable, UCB RISC-V, version 1 (SYSV), not stripped09:40
*** miip24 has joined #timvideos09:44
*** miip24 has quit IRC09:46
mithrothe BIOS seems to compile fine09:48
mithroAny idea how to figure out which module has the hard-float modules09:48
*** AJaeger0 has joined #timvideos09:49
xobsmithro: If it's anything like ARM, "readelf -a" should tell you... somewhere09:49
*** AJaeger0 has quit IRC09:49
mithroHrm... It seems the compile of the assemble boot helper file09:49
mithroriscv32-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/include09: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.o09:51
mithrocompared too09:51
mithroriscv32-unknown-elf-gcc -std=gnu99    -c -o boot-helper-vexriscv.o boot-helper-vexriscv.S09:51
xobsmithro: use -mabi=ilp32d or ilp32f?09:56
xobsOr specify ilp32 for the rest of the files, to force soft-float09:57
mithroI'm very confused about the assembly line dropping the CFLAGS09:57
xobsIs it a different variable such as ASFLAGS?09:58
mithroLooks like an issue with implicit rules...10:05
tpbTitle: firmware: Add manual assembly for boot-helper file. · timvideos/[email protected] · GitHub (at
auscompgeekif you're using implicit rules, yeah, you'd want to set ASFLAGS as well10:06
auscompgeeksee make's info(1) page about implicit variables10:06
*** mishehu8 has joined #timvideos10:25
*** dshin10 has joined #timvideos10:25
*** mishehu8 has quit IRC10:26
*** netg2 has joined #timvideos10:28
mithroWOOT! ->
mithroThe following builds succeeded10:42
mithroarty base vexriscv10:42
mithroarty net vexriscv10:42
xobsAs it says: \o/10:42
mithro LD       firmware.elf10:47
mithroriscv32-unknown-elf-ld: firmware.elf section `.bss' will not fit in region `sram'10:47
mithroriscv32-unknown-elf-ld: region `sram' overflowed by 720 bytes10:47
mithroWonder if it will build ->
*** DeMiNe0_ has joined #timvideos11:12
*** DeMiNe0_ has quit IRC11:14
*** CarlFK has joined #timvideos11:44
*** ChanServ sets mode: +v CarlFK11:44
*** tsglove has quit IRC11:58
*** tsglove has joined #timvideos12:03
*** uriah3 has joined #timvideos12:20
*** uriah3 has quit IRC12:24
*** rohitksingh_work has quit IRC12:43
*** Kripton has quit IRC13:00
*** Kripton has joined #timvideos13:04
*** Otyg7 has joined #timvideos13:07
*** rohitksingh has joined #timvideos13:21
cr1901_modernJust put .bss into main_ram?13:54
cr1901_modernI've done it before for the xmodem stuff- it doesn't harm anything13:54
*** Airwave25 has joined #timvideos13:55
*** rohitksingh has quit IRC14:28
*** rohitksingh has joined #timvideos14:41
*** mgor_ has joined #timvideos14:52
*** mgor_ has quit IRC14:55
*** hermann_nordung has joined #timvideos15:15
*** hermann_nordung has quit IRC15:17
*** Guest99579 has joined #timvideos15:29
*** Guest99579 has quit IRC15:34
*** rohitksingh has quit IRC16:45
*** wolfshappen12 has joined #timvideos17:32
*** wolfshappen12 has quit IRC17:37
*** TecKnow has joined #timvideos18:05
*** TecKnow has joined #timvideos18:09
TecKnowThis is David from PS1 looking for Carl. I hope I'm in the right place.18:10
CarlFKyou are!18:12
CarlFKexcelt I am runiing out the door18:12
CarlFKand.. Tim's flight got canceled, so he wont'  be to PS1 till about 4pm tomrrow :(18:12
CarlFKTecKnow:  I'll be in a few wating rooms in the next hour or to, can get back to you on and off18:13
*** CarlFK has quit IRC18:13
*** puck_ has quit IRC18:45
*** puck_ has joined #timvideos18:47
*** persia25 has joined #timvideos19:38
*** persia25 has quit IRC19:41
*** TinyTimmyTokyo0 has joined #timvideos19:49
*** TinyTimmyTokyo0 has quit IRC19:51
*** prg31810 has joined #timvideos20:04
*** prg31810 has quit IRC20:15
*** TecKnow has quit IRC20:47
*** CarlFK has joined #timvideos20:49
*** ChanServ sets mode: +v CarlFK20:49
CarlFKim back for the day20:54
*** MrNr1 has joined #timvideos20:55
TheAssassinever thought about using some (proprietary) HDMI receiver chip to provide cheap capturing?21:08
TheAssassine.g., IT6604E21:08
TheAssassinthese chips are just a couple of dollars in china, and even decrypt HDCP21:09
TheAssassinyou'd just need a high-performance USB "gateway" thingy providing a raw or even encoded stream over USB21:09
TheAssassinsure, they're SMD chips, so you'd need some sorta "custom SMD PCB", but that'd be possible, I guess21:10
CarlFKI can see this going two ways:21:11
CarlFK1. IT6604E does a better job than what we are currently doing with the fpga,  so lets us do higher res/framrate - good.21:17
CarlFK2. 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 gain21:18
CarlFKIm thinking the R&D to prototype it will be 'hard'21:27
TheAssassinwell, I just thought one could use such "standard chips" like that one to save some work and especially a lot of money21:47
TheAssassinthis chip is used in really cheap HDMI equipment such as these "range extenders" which are in fact just creating a livestream21:47
TheAssassinthey just add a hw encoder (h.264 or MJPEG) and some magic and it just works21:48
TheAssassinI know it wouldn't be fully open source, but perhaps could result in a better price point21:48
TheAssassin>300 USD for the hardware you guys designed, that's damn expensive21:49
TheAssassinis the problem to get some USB3 hw that interfaces with the chip and the USB host providing enough bandwidth?21:51
TheAssassinfor 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
TheAssassinbut for testing a USB board would be great21:52
*** anairo has joined #timvideos22:11
*** anairo has quit IRC22:12
CarlFKI suspect one problem is finding a dev board like the Atlys22:16
*** fitzsim has quit IRC22:57
*** royal_screwup213 has joined #timvideos23:51
*** Kripton has quit IRC23:52
*** royal_screwup213 has quit IRC23:55

Generated by 2.13.1 by Marius Gedminas - find it at!