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.



Thanks,
Chao
在 2023/11/9 06:21, Laszlo Ersek 写道:
> 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


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111010): https://edk2.groups.io/g/devel/message/111010
Mute This Topic: https://groups.io/mt/102413885/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-