Hi Laszlo,
Sorry, it is my fault, I should separate this this patch for two standalone patches, and with some detailed commit message. I will fix this in V3.
Currently, there are two libraries are not independent, so I guess you are talking about Fdt16550SerialPortHookLib. I would say that the different is not in GetSerialConsolePortAddress, the logic about this function is same to ARM, the different is in PlatformHookSerialPortInitialize. Since some platform do not require running code on memory during the PEI phase, so the ARM version of PlatformHookSerialPortInitialize will use PcdSet to set a PCD value, if the memory is not ready, this funciton can not be used. So this library is override from ArmVirtPkg to LongArchVirt.
BTW, the new library FdtSerialProtAddressLib which you committed a few days ago, I will look into it and try it. Roughly speaking, it is look like the code for obtaining the serial port address is sparated from the HookLIb. I have a question, can I move this library to OvmfPkg so that other ARCH can use it easily?
Regarding FdtSerialPortAddressLib, I would like to
say that it was not committed when I porting LoongArchVirt, my
code base is based on stable202308, so I don't know you
committed a new library, sorry.
On 11/7/23 11:12, Chao Li wrote:Hi Gerd, These two libraries is not only copy code, the way of obtain the serial base address is different from ARM, and the early serial port output also different from ARM, so these two libraries are LoongArch specific.I think we're going to have to go through the design with "baby steps". The commit message of the patch is empty. Please don't expect reviewers to "reverse engineer" the design from the code. That's hugely taxing. It's hard enough to review code when we precisey know in advance, from the commit message, what the code will try to achieve. You are saying that the way to obtain serial base address is different from ARM, yet the GetSerialConsolePortAddress() function looks very similar to the function that I *replaced* in recent commits eb83b5330961 ("ArmVirtPkg: introduce FdtSerialPortAddressLib", 2023-10-26) and f078a6fdd4d7 ("ArmVirtPkg/Fdt16550SerialPortHookLib: rebase to FdtSerialPortAddressLib", 2023-10-26). So there are two issues with your GetSerialConsolePortAddress() function immediately, I would say: - you say that it's different from ARM, but it seems to parse the DTB identically (or mostly identically -- I'm speaking from memory), - I factored out the subject DTB parsing logic in the above-noted commits recently, so even if your GetSerialConsolePortAddress() function is *supposed* to parse the DTB identically to ARM, then the way to employ that logic is different; it should be reused, not duplicated. Now that you have a running prototype (basically evidence that the port to this new architecture can be done), can we go through the design of each component (library, driver etc) one by one? Dumping the whole thing on reviewers all at once, with little documentation, is not helpful. We basically need to start with the specification of each of your modules. See where the existing components in edk2 are not good enough or not flexible enough, etc. Laszlo