Hi Heinrich, On Wed, Mar 27, 2024 at 12:03:01PM +0100, Heinrich Schuchardt wrote: > [EXTERNAL MAIL] > > On 24.03.24 16:00, Aurelien Jarno wrote: > > On 2024-03-21 19:11, Heinrich Schuchardt wrote: > > > The differences between the Milk-V Mars board and the VisionFive 2 board > > > are small enough that we can support both using the same U-Boot build. > > > > > > * The model and compatible property are taken from proposed Linux patches. > > > * The EEPROM is atmel,24c02 according to the vendor U-Boot. > > > * The second Ethernet port is not available. > > > > From the device tree that have been submitted to the kernel [1] it seems > > another difference is that there is a CD gpio for mmc1. > > Yes, the Mars board has > > cd-gpios = <&sysgpio 41 GPIO_ACTIVE_LOW>; > > while the VisionFive 2 has > > broken-cd; > > We could add the cd-gpios to the VF2 dts and then set broken-cd in > spl_fdt_fixup_*(). > > What I would really like to understand from the reviewers is if the > approach with patching the device-tree is what we are targeting for. > > Or should we try to keep the device-trees in sync with Linux, package > all JH7110 device-trees into the FIT image and in SPL choose the > device-tree from the fit image and only patch the memory size. > > The device-tree for the Milk-V CM module differs a lot in GPIO routing. > I am not sure that patching the VF2 device-tree is future proof.
I think we could patch the VF2 device-tree currently with this few differeces, and create a new device tree for Milk-V Mars CM module if patching the VF2 device tree is too much of an effort. Does this sound reasonable ? Do you have any preference over which scheme we should use ? Best regards, Leo > > Best regards > > Heinrich > > > > > > From the schematics, it also seems that the usb0 port is not in > > peripheral mode, but in host mode. That said on the submitted kernel > > device tree it seems simply disabled. > > > > Aurelien > > > > [1] > > https://lore.kernel.org/linux-kernel/20240131132600.4067-2-jszh...@kernel.org/T/ > > >
