On Tue, 24 Jan 2023 at 08:21, Christian Helmuth christian.helmuth@genode-labs.com wrote:
Hello,
On Mon, Jan 23, 2023 at 15:56:48 CET, Michael Grunditz wrote:
On Mon, 23 Jan 2023 at 14:15, Michael Grunditz michael.grunditz@gmail.com wrote:
Anyway init crashes somewhere.
2043 MiB RAM and 64533 caps assigned to init no RM attachment (READ pf_addr=0x81 pf_ip=0x9f3f4 from pager_object: pd='init' thread='init') Warning: page fault, pager_object: pd='init' thread='init' ip=0x9f3f4 fault-addr=0x81 type=no-page
I *think* it fails right in start of first child. It seems ok around the starting. The last memcpy seems ok. I have printed both buffers and they are identical.
I'm wondering why you replaced the general memcpy() in the first place as this brings maximal (potential negative) impact in many places. You could alternatively just optimize your framebuffer blitting and proceed with your porting work.
Yes you are absolutely right. I just got a bit excited about what might be gained.
Also, it is not known which NEON instructions and registers your memcpy utilizes. I'm not an ARM expert but: Does the current FPU-switching implementation of base-hw suffice or do you need to save/restore extended state? As you do not share your developments (i.e. source code) with the public it is hard to provide specific help.
Right again.
Any information which code is at 0x9f3f4 in ld.lib.so?
No.Sorry. At the top level it crashes at the first elf starting, init. It seems to be able to start the thread but fails in the jump ( or something ).
Anyway I will stop doing this little hack. Sorry for sending unwanted email and thanks for reading!
About the blitting: I will do benchmarks with and without clipping/flushing.
Also: I want to put things together in a target tree and publish that on github and at the same time rebase everything to git level. I think this is the task I will do first. Things are scattered across several repos now, and it is quite hard to handle. I also want to be open with what I am doing.
Thanks for you patience,
Michae