<NotHet>
hey yall. i've got a riscv soc built with litex and I'm trying to boot zephyr. I can see it booting and get the "uart:~$" prompt on the shell subsystem sample. Problem is that it doesn't seem to be recieving any bytes I type into the console
<NotHet>
I know the liteuart works both ways, as I am using lxterm to download the zephyr kernel during boot.
<NotHet>
I was thinking I was going to go start poking into the riscv core and see if I can get the logic analyzer attached to the instruction pointer. But debugging a riscv core I've never touched before is gonna be an effort
<NotHet>
any ideas what to go looking for? or better yet solutions to the problem lol
<NotHet>
So I rebuilt without ethernet, still no go.
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #litex
<NotHet>
I kind of suspect the CPU is hanging, but I don't know how to prove that. Etherbone has been working, but with ethernet on the soc DHCP fails in Zepyhr without ever hitting the net_mgmt_event_callback.
<NotHet>
Another point to something going very wrong: it never returns from a k_msleep. Like even if I modify hello world to a while(1) { kprintf() k_msleep() } never prints more than once
Degi has quit [Ping timeout: 245 seconds]
Degi_ has joined #litex
Degi_ is now known as Degi
geertu has quit [Ping timeout: 250 seconds]
geertu has joined #litex
<NotHet>
Yeah Zephyr has some kernel deadlocking going in arch_swap
linear_cannon has quit [Ping timeout: 245 seconds]
linear_cannon has joined #litex
NotHet has quit [Remote host closed the connection]
<Melkhior>
_florent_: still trying to resolve my FB issue...
<Melkhior>
another one I'm not 100% sure of the fix: my monitors hate it when the R/G/B signals are not 0 during the blanking
<Melkhior>
(using VGA)
<Melkhior>
if I limit the non-0 output of R/G/B to DE being high, then the monitors are much happier
<Melkhior>
but I'm still short on BW - my 8 bit device is running out of BW (i *think*) for 1280x1024 @ 60 Hz, which should only be 75 MiB/s
<Melkhior>
ot something else - even at 800x600@60 Hz the display is corrupted
<_florent_>
Melkhior: Sorry I've not yet been able to also do some tests on my side at high resolutions
<Melkhior>
no problem, I suspect there's something weird about my setup
<Melkhior>
now that I have identified the sync issue, I'll try again ASAP with 'normal' Litex on the Wukong
<Melkhior>
as that's more reproductible
<Melkhior>
OK; so on regular litex with my wukong setup, 800x600@60Hz/16bpp works, 1024x768 doesn't sync properly, 1280x1024 is fone, and 1920x1080 is fine except the FB memory run well into the DTB space, which I suspect is why Linux is crashing
<Melkhior>
s/fone/fine/
<Melkhior>
so on that setup, it seems BW is fine ; why my monitor won't accept XGA signal I don't know
<Melkhior>
TBC
<Melkhior>
So when I move the FB memory a bit lower to avoid running into rv32.dtb (while having enough space for the kernel), Linux boot just fine with the 1920x1080x16bpp FB
<Melkhior>
there's only a bit less than 3 MiB available with the default memory map/json file, so anything above 800x600x32bpp will have issue
CarlosEDP has quit [Read error: Connection reset by peer]
jryans has quit [Write error: Connection reset by peer]
david-sawatzke[m has quit [Read error: Connection reset by peer]
jevinskie[m] has quit [Read error: Connection reset by peer]
vomoniyi[m] has quit [Write error: Connection reset by peer]
sajattack[m] has quit [Read error: Connection reset by peer]
DerekKozel[m] has quit [Read error: Connection reset by peer]
willcode4[m] has quit [Read error: Connection reset by peer]
dmiller[m] has quit [Remote host closed the connection]
dcallagh has quit [Read error: Connection reset by peer]
amstan has quit [Read error: Connection reset by peer]
Crofton[m] has quit [Write error: Connection reset by peer]
promach[m] has quit [Write error: Connection reset by peer]
HumbertoJimenez[ has quit [Read error: Connection reset by peer]
kaji has quit [Write error: Connection reset by peer]
shoragan[m]1 has quit [Write error: Connection reset by peer]
a3f has quit [Remote host closed the connection]
bluecmd has quit [Remote host closed the connection]
Las[m] has quit [Remote host closed the connection]
leons has quit [Write error: Connection reset by peer]
jryans has joined #litex
shoragan[m] has joined #litex
CarlosEDP has joined #litex
jevinskie[m] has joined #litex
dcallagh has joined #litex
kaji has joined #litex
leons has joined #litex
promach[m] has joined #litex
Las[m] has joined #litex
Crofton[m] has joined #litex
amstan has joined #litex
sajattack[m] has joined #litex
david-sawatzke[m has joined #litex
vomoniyi[m] has joined #litex
DerekKozel[m] has joined #litex
HumbertoJimenez[ has joined #litex
dmiller[m] has joined #litex
willcode4[m] has joined #litex
a3f has joined #litex
bluecmd has joined #litex
key2_ is now known as key2
<_florent_>
Melkhior: OK, the the issue seems related to your other setup?
<_florent_>
Melkhior: Sorry I'm not sure to remember the config on this other setup, can you share it again? (to be able to compare with the Wukong board)
<Melkhior>
it's my custom, cpu-less (devices only) setup for my SPARCstation
<Melkhior>
the one thing that is 'standard' is the sdram, using add_sdram()
<Melkhior>
the FB is meant to be 8-bits pseudocolor to be compatible with the host software
<_florent_>
and which kind of dram is it?
<Melkhior>
same as the wukong - 16 bits DDR3, sys_clk_freq is also 100 Mhz
<Melkhior>
(so far I've set it to 8-bits grey, copying the 8 bits in R/G/B and bypasing the CLUT to remove one variable)
<Melkhior>
but I need to track down the issue accurately, by checking the 'valid' bits of every element in the sequence of stream (dma, conv, cdc) to figure out which one is slowing things down
<Melkhior>
it seems unlikely to be the memory now, as the Wukong as enough to run several time the bandwidth
<Melkhior>
needed for the SBusFPGA
<Melkhior>
my week-end will be busy :-)
NotHet has joined #litex
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 245 seconds]
FabM has quit [Remote host closed the connection]
peepsalot has joined #litex
peeps[zen] has quit [Ping timeout: 252 seconds]
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 265 seconds]
<Melkhior>
_florent_: seems the issue might not be the hw, just relooked at the driver, i probably have a mapping issue somewhere
<Melkhior>
sigh...
peepsalot has joined #litex
peeps[zen] has quit [Ping timeout: 245 seconds]
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 245 seconds]
<Melkhior>
_florent_: actually, once the SW side is sorted, 1280x1024 in 8 bits is fine in my design as well
NotHet has quit [Remote host closed the connection]
<Melkhior>
As of a few seconds ago, I have the only SPARCstation in the universe with a 1280x1024 cg3, running X11, controlled by a USB mouse :-)
<Melkhior>
colors are ugly because I only have RGB222 output (custom Pmod, VGA with just 8 pins)
<Melkhior>
happy :-)
<_florent_>
nice! By curiosity, do you have a picture of your unique SPARCstation? :)
<geertu>
Melkhior: congrats!
<Melkhior>
geertu: thanks :-)
<Melkhior>
_florent_: just of the new board with its plugs, I'll add it to GitHub tomorrow
<Melkhior>
BTW, at 1920x1080 i don't pass timing with the CLUT, but i do without, so I'll need to figure out how to fix that at some point
<Melkhior>
(the CLUT is just three 256 8 bits array indexed by the video_pipe_source.data)
<Melkhior>
the SPARCstation itself is one of my least photogenic (it had a tough life before meeting me; lots of broken plastic), developing HW is a risky business for such old beasts :-/
<Melkhior>
and it would not have been possible without Litex !
<Melkhior>
Is there an 'official' logo that would look OK in 64x64, as few colors as possible? Not sure how to implement the draw-logo in the framebuffer but the option exists so some day it will need a proper Litex logo instead of the Sun one at boot :-)
<Melkhior>
geertu: BTW, not sure how to do a console-supported 24-bits framebuffer, but some GX documentation have surfaced so I might give a go at adding some acceleration at some point and emulating a cg6 instead of a cg3
<Melkhior>
Right now I'm thinking a simple VexRiscv with no MMU or interrupt or anything, and emulate the blit, draw and font command in software
<Melkhior>
no idea how to implement the HW cursor though...
<Melkhior>
cg3 are *slow*
<Melkhior>
good night all :-)
<geertu>
Melkhior: All console acceleration has been dropped from upsream :-(
<geertu>
But fbcon does support 24/32 bpp
<Melkhior>
geertu: SPARCstation have been dropped from Linux entirely, I'm using NetBSD, acceleration is still available there
<Melkhior>
I should have been clearer: "console" as the PROM-based console, before the boot; so I need to implement the firmware in Forth (OpenFirmware)
<Melkhior>
1-bit and 8-bits are 'easy' as there's built-in function you can use - and I just reused the code from OpenBIOS anyway :-)
<geertu>
Melkhior: oh. right
<Melkhior>
24-bits, not so easy :-(
<Melkhior>
geertu: you mentioned higher bit depth in a previous discussion hence my comment
<Melkhior>
And maybe someday there will be a NuBus version :-) , though I don't know how the firmware work on that
<Melkhior>
I have a IIvi in unknown condition, but it was working when put in storage many years ago
<Melkhior>
and there's a lot more m68k vintage enthusiasts than sparc...
peeps[zen] is now known as peepsalot
Guest5374 has quit [Quit: Client closed]
RichardSnow has joined #litex
<RichardSnow>
hi
<RichardSnow>
I was trying to rebuild the Litex VexRisv linux with build root and it fails on autoreconfiing of host-fakeroot
<RichardSnow>
I wanted to change the eth0 to use dhcp and add bind so that dns resolvss and add a development package or two such as 4th and Python3