Hi Dmitry, On Fri, 1 Dec 2023 at 20:04, Dmitry Malkin <dmi...@bedrocksystems.com> wrote: > > 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?
You may as well. Do the Raspberry Pi Foundation or Broadcom help with this effort? I wonder if it might be possible to coax them towards open source firmware? Regards, Simon