#timvideos

FelixVi: Yes

so shouldn't I get rid of gateware size as we're counting that twice now?

FelixVi: But we leave a gap in the flash image so that we have a consistent flash layout

oh, nvm

now I get it

but then what's the bios size for?

FelixVi: Also makes it easier to switch to a bios from flash at a later date

I'd upload to 0x200000 and isn't that where we'd start executing?

oh, so bios_size should be 0 for now - and if there's flash bios that will change

or i need to upload firmware to 0x200000 + 20000

that way, I can just leave space for a flash bios if I want that later on?

so, if I synthesized this now, I'd upload top.bit with bios to 0x0 and firmware to 0x204E20

alright, bios is talking with me

and it's trying to boot from flash

but it says flash boot image length is invalid (0x0000000)

FelixVi: Great!

thanks! This would have taken me weeks

FelixVi: I would upload the firmware to 0x200000 + 20000

yeah, that's what i did

FelixVi: So, the next thing is to figure out if your flash is working at all

FelixVi: This is where cr1901_modern comes in

where is the flash image length defined?

if that was correct, we'd know in a sec

oh, or is it trying to read the length from flash to begin with?

I suppose I could try to write/read from flash if I knew how it's mapped

so, at 0x20000000, I just see all zeroes

and using mw 0x20000000 1 2 3 4 and then reading back with mr 0x20000000 yields all zeroes

if I'm using the commands correctly, flash is not working

I don't seem to be able to write to 0x0 either, though

this seems to be where flashboot fails: https://github.com/m-labs/misoc/blob/master/mis...

Title: misoc/boot.c at master · m-labs/misoc · GitHub (at github.com)

I am not exactly positive on "length = *flashbase++;" and why it's written like that

mithro/FelixVi: Not available right now, sorry

shenki: I think I got it now, it looks like calling convention issues with syscall(2).

FelixVi: You won't be able to write to the flash

FelixVi: (from the BIOS that is)

ah, that explains that

cr1901_modern: Do you think you'll be around later today?

I'm basically trying to figure out if I want to stay at work or drive home

FelixVi: By all means, drive home. I have other things to check off my todo list personally

cr1901_modern: Cool, should I place an issue report about flash or is that the same as letting you know in here?

FelixVi: I'll take care of that when we diagnose the problem

well, I guess I did that already in misoc anyways - but if you think it's worthwhile I can add detail there

FelixVi: Can you work from home at all?

cr1901_modern: Yeah, I can be on later tonight if that's helpful

I just need to take the working saturn board as mine at home is shot - that was a painful lesson

FelixVi: That would work better if we could continue work when you get home

or we can continue tomorrow if that works better for you

alright, I'll take it and let you know when I'm around

Alright cool

mithro: Did you ever take a look at my PR for flash updates as-is?

cr1901_modern: No I haven't had a chance -- lots of things to do

We agreed to merge it in despite having simulation issues

mithro: Good, that makes two of us

No rush at all

cr1901_modern: Oh, I needed to chat with you about the xmodem support in flterm -- it seems to be causing problems, can we move it behind a flag?

mithro: Yes

Go for it

Prob no need for it to be mutually exclusive w/ sfl either

(it == the flag)

cr1901_modern: k, got everything setup here again - getting "Error: Invalid flash boot image length 0x00000000" again

FelixVi: Ack, give me a few minutes please

cr1901_modern: No rush, just wanted to give you a heads up

I'm looking to switch over to mitex - it doesn't fix misoc but might work out of the box and also seems to be better commented

*litex

I mean, it should work. But I would prefer that your changes are contributed/test on both to avoid divergence.

(Do as I say, not as I do)

cr1901_modern: yeah, whatever we get fixed I'll write up as a PR

cr1901_modern: https://gist.github.com/mithro/289c5dce5fd1c4ea...

Title: Prepare an upstream migen/misoc for merging into litex · GitHub (at gist.github.com)

mithro: Okay, this makes me feel _much_ better. I have no idea how/why it works, but clearly you put thought into it.

cr1901_modern: The aim there is to try and get LiteX / migen+misoc closer together again

mithro: So my intent was to at the very least make litex PRs for the two platforms I added to migen/misoc since I started my current round of PRs. >>

if you decide to run this script later, would the end merge of my two PRs be equivalent as if I never bothered sending the PRs at all?

(and just let your script add the new platforms instead)

Easier q: Should I just keep making PRs to migen/misoc and let your script handle merging in changes? Or should I make equivalent PRs for each migen/misoc feature I need to get tinyfpga running?

(Some PRs I made to migen/misoc are irrelevant to litex)

cr1901_modern: Could you get stuff into LiteX sooner rather than later?

mithro: is it OK to ask you a question or two about targets in litex? I'm trying to port Saturn to litex so that we can work on that directly

here's me trying to add Saturn to litex - what I can't figure out is how to just build the basesoc: https://github.com/FelixVi/HDMI2USB-litex-firmw...

Title: Adding Saturn · FelixVi/HDMI2USB-litex-firmware@c024ee5 · GitHub (at github.com)

FelixVi: export TARGET=base

FelixVi: You don't want lines 207/208 -- https://github.com/FelixVi/HDMI2USB-litex-firmw...

Title: Adding Saturn · FelixVi/HDMI2USB-litex-firmware@c024ee5 · GitHub (at github.com)

NameError: name 'BaseSoc' is not defined

what might this be about?

It's BaseSoC* I think

hmm, it works in mimasv2 but not saturn

Of course it does ._.

Just once, I would like _one_ solution I propose these past 2 weeks to be right XD.

well, you got more right than me so far ;)

I'm slowly getting used to misoc/litex though - FWIW

doh - I think it's the 'c' which needs to be "C"

that's progress - now it complains about the uart phy

Title: python3 make.py --platform saturn Traceback (most recent call last): File " - Pastebin.com (at pastebin.com)

this is the traceback

I'll see if I can figure this out - mimasv2 didn't complain about this

(11:03:16 PM) FelixVi: doh - I think it's the 'c' which needs to be "C"

(10:59:16 PM) cr1901_modern: It's BaseSoC* I think

:P

well, point is that it works now ;)

FelixVi: I am not exactly positive on "length = *flashbase++;" and why it's written like that <-- flash image is supposed to embed the length of the image

as well as a checksum

I think it takes the length from the first object at the base pointer and increments it by 1

then takes the crc from there

but why it's written like that is a mystery to me

B/c it works :P

you need to know the operator priority to figure out what it does

so IMO writing it in explicit notation makes it easier to read

++ has low priority. It's one of the last things done

but either way, it does not find a valid length, so I assume we're not actually reading from flash :P

Did you update the flash to use spiflash1x?

when it's on the right yes, but I think on the left it would get resolved before dereferencing

either way, the fact that we talk about it means the notation is not readable

unless the mantra is to minimize lines in the code

*b++ = *a++ is a common memcpy idiom

but that's not really important

agreed

I want to know whether you changed the spiflash to use 1x

spi_flash.SpiFlashSingle is what I use

but we get hung up on serial configuration as of now

please show me your code

hold on - is it more convenient for you to work on misoc or litex?

focus on litex for now

Title: HDMI2USB-litex-firmware/base.py at 120c39e8c5c2b16c034e31141ae3bc8d72ba7cf2 · FelixVi/HDMI2USB-litex-firmware · GitHub (at github.com)

and the traceback as seen above is what I got from this

I think line 169 is likely the problem

well, but it defaults to 115200 in soc_core.py

I have no idea, I've never seen this error before

it seems like tx is not assigned

It clearly is though, since it's in your platform file

but one of the terms in uart.py L85-89 is not recognized as migen statement