#timvideos

ok, was able to hack out a log

[ 0.000000] Kernel command line: earlycon

[ 0.000000] BUG: failure at /home/shorne/work/litex/litex-buildenv/third_party/linux/lib/ioremap.c:166/ioremap_page_range()!

[ 0.000000] Kernel panic - not syncing: BUG!

thats just the end

riscv32-unknown-elf-ld: boot-helper-vexriscv.o: can't link hard-float modules with soft-float modules

riscv32-unknown-elf-ld: failed to merge target specific data of file boot-helper-vexriscv.o

shorne: Did you see xobs' comments?

mithro: about debugger? yes

I am using the debugger to look at this

shorne: about the wrong spi flash version stuff?

no

but got to go now

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.

build/arty_net_vexriscv/software/firmware/boot-helper-vexriscv.o: ELF 32-bit LSB relocatable, UCB RISC-V, version 1 (SYSV), not stripped

the BIOS seems to compile fine

Any idea how to figure out which module has the hard-float modules

?

mithro: If it's anything like ARM, "readelf -a" should tell you... somewhere

Hrm... It seems the compile of the assemble boot helper file

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

-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

/home/tansell/github/timvideos/HDMI2USB-litex-firmware/third_party/litex/litex/soc/software/bios/boot-helper-vexriscv.S

compared too

riscv32-unknown-elf-gcc -std=gnu99 -c -o boot-helper-vexriscv.o boot-helper-vexriscv.S

mithro: use -mabi=ilp32d or ilp32f?

Or specify ilp32 for the rest of the files, to force soft-float

I'm very confused about the assembly line dropping the CFLAGS

Is it a different variable such as ASFLAGS?

Looks like an issue with implicit rules...

Title: firmware: Add manual assembly for boot-helper file. · timvideos/litex-buildenv@e1afe96 · GitHub (at github.com)

if you're using implicit rules, yeah, you'd want to set ASFLAGS as well

see make's info(1) page about implicit variables

WOOT! -> https://travis-ci.org/mithro/litex-buildenv/job...

The following builds succeeded

=============================================

arty base vexriscv

arty net vexriscv

As it says: \o/

Grats

LD firmware.elf

riscv32-unknown-elf-ld: firmware.elf section `.bss' will not fit in region `sram'

riscv32-unknown-elf-ld: region `sram' overflowed by 720 bytes

Wonder if it will build -> https://travis-ci.org/mithro/litex-buildenv

Just put .bss into main_ram?

I've done it before for the xmodem stuff- it doesn't harm anything

This is David from PS1 looking for Carl. I hope I'm in the right place.

you are!

excelt I am runiing out the door

and.. Tim's flight got canceled, so he wont' be to PS1 till about 4pm tomrrow :(

TecKnow: I'll be in a few wating rooms in the next hour or to, can get back to you on and off

im back for the day

question:

ever thought about using some (proprietary) HDMI receiver chip to provide cheap capturing?

e.g., IT6604E

these chips are just a couple of dollars in china, and even decrypt HDCP

you'd just need a high-performance USB "gateway" thingy providing a raw or even encoded stream over USB

sure, they're SMD chips, so you'd need some sorta "custom SMD PCB", but that'd be possible, I guess

I can see this going two ways:

1. IT6604E does a better job than what we are currently doing with the fpga, so lets us do higher res/framrate - good.

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

Im thinking the R&D to prototype it will be 'hard'

well, I just thought one could use such "standard chips" like that one to save some work and especially a lot of money

this chip is used in really cheap HDMI equipment such as these "range extenders" which are in fact just creating a livestream

they just add a hw encoder (h.264 or MJPEG) and some magic and it just works

I know it wouldn't be fully open source, but perhaps could result in a better price point

>300 USD for the hardware you guys designed, that's damn expensive

is the problem to get some USB3 hw that interfaces with the chip and the USB host providing enough bandwidth?

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)

but for testing a USB board would be great

I suspect one problem is finding a dev board like the Atlys