[PATCH v2 0/3] rpi5: initial support

[Peter Robinson]

Hi Dmitry,

> First of all, thank you for all your reviews. I hope I can answer all
> your questions here. If I forget something please let me know.

Absolutely.

> I don't have much experience with arm/arm64 and I don't have previous
> experience with u-boot and contributing to it. So please guide me for
> next steps.

I think you're doing fine, generally the process is wait for some
review, incorporate the feedback into patches and after a little while
send a new rev.

> Also I don't think it makes sense to expect all devices or any device
> may/should work after initial boot support. I would suggest going with
> small steps and talking about gfx/usb/net/mmc in dedicated patchsets
> after initial support is being merged.

I agree with that point mostly, and that is my intention, from my PoV
it was more me replying to the comments you had made about outsanding
issues and what my thoughts were to address them.

That being said I think we need two things to be able to land this
upstream 1) working output such as serial console (this is ticket) 2)
working storage so it can load things like the Linux kernel off disk
and boot, the shortest path to this is likely MMC. Everything else
(gfx/net/usb etc) can be added later in incremental patches. I
apologies if my reply didn't come across at that, it was as much
documented my discoveries for everyone else on the list following
along.

> > Could this be the title for the patch, "initial support" is fine for
> > the cover letter, but doesn't really out line what this specific patch
> > actually does.
> Can confirm. My bad. Will fix it in the next patchset.
>
> >> includes:
> >> * 1GB of RAM (from 4GB or 8GB total)
> >> * VPU memory interface
> >> * SOC range (main peripherals)
>
> > Could you include details where this information came from as well please?
> By looking into FDT for memory, framebuffer, and soc nodes. I can add
> this info in v3.
>
>
> > When you say it doesn't work, does it just not output display or does
> > the device lock up and you need to disable it?
> There are artifacts on the screen and the system locks up.

OK, good to know, we can't really disable display ATM as it'll regress
other rpi devices supported in this config.

>
> > For the rpi4 it was as simple as adding a new compatible [1] for the
> > rev6 of the IP block as for the bits that we use in U-Boot nothing
> > changed, but the kernel changes for the rev7 that's in the RPi5 needed
> > updating registers [2] so I'm not sure if we're going to need to do
> > more for this or not.
> I've tried it by playing with "simple-fb" and with "bcm2712-hdmi0".
> And no luck. Still visible artifacts on the screen. I see valid debug
> output from bcm2835_video_probe() so the mailbox for set/get
> base/resolution/pitch/stride works. But still observe the same issue
> with artifacts and lock up. FYI by default the probing starts due to
> "bcm2708-fb".
>
>
> > Might be worth looking to see if there's changes in the kernel for
> > this. In an initial look I didn't see any changes to their kernel
> > here.
> I don't see any changes either. I'm not able to find any official
> confirmation. But most of 'tags' work except two or three. And all of
> them have response code 0x8000_0001. And FDT contains new info
> compared to old versions (for these tags). Which leads to the
> conclusion they are deprecated.
>
>
> > We probably need a patch to the identifier too similar to the following:
> > https://source.denx.de/u-boot/u-boot/-/commit/5e7e6619c85c090f6b62685a9d90f748f1729d12
> Honestly I didn't get the reason/goal besides old/new scheme except
> there is a final print:
> > printf("RPI %s (0x%x)\n", model->name, revision);
> which is kind of simular to my:
> > printf("FW FDT model : %s\n", fdt_model);

The main reason for the detection is if there needs to be a kernel DT
loaded off disk, it's a more definitive way of detecting the HW rev
because the fdt model could be repeated across different revs of the
same variant.

> Besides parsing the "Raspberry Pi 5 Model B Rev 1.0" string to get
> revision from it? Format is unknown and nobody knows what will be
> changed. Will it be "Raspberry Pi 5 Model B Rev 1.0a" or Raspberry Pi
> 5 Model B Rev 1.01"? I don't know. If it's really needed then I would
> suggest parsing OTP to get precise info with known format.

Hence the reason to use the official hex identifiers.

> P.S.: Please let me know if I answered all the questions so I can send v3.

I think so. The outstanding things we will need to resolve to land
this, other than the polish I've outlined in various replies, is:
1) working storage to load an OS
2) not disabling the display driver and not have it crash. The display
on the rpi5 doesn't need to work, we just don't want to regress
existing users.

This won't be landing in 2024.01 now so we have time to get this
ready. I'll start to play in the coming days.

Peter