[PATCH v2 0/3] rpi5: initial support

[Dmitry Malkin]

Hi Peter,

> I've given these a cursory look over, I have a system to test and will
> give them a whirl in the next few days, I was planning to start
> playing over the weekend so you've provided a great start :)

Did you have any chance to test my patches?



>
> Hi guys,
>
> 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.
>
> 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.
>
> 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.
>
> > 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.
>
>
> > 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);
>
> 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.
>
> P.S.: Please let me know if I answered all the questions so I can send v3.
>
> Regards,
> Dmitry

I haven't heard any updates. Should I send v3?