9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] a64/arm64 mmu
@ 2025-01-26 23:37 Dave MacFarlane
  2025-01-28 22:01 ` Dave MacFarlane
  0 siblings, 1 reply; 2+ messages in thread
From: Dave MacFarlane @ 2025-01-26 23:37 UTC (permalink / raw)
  To: 9front

I'm trying to update adventurein9's Allwinner A64 kernel to use the 
generic arm64 code in 9front.  I think I've done most of the work, but 
as far as I can tell there's a bug (in my changes, not in 9front) 
where the virtual addresses aren't working after mmuenable in l.s. 
WAVEs work before mmuenable.  Nothing goes to the uart after (either 
VWAVE or prints).  I'm hoping someone who knows the code/architecture 
better than I do might have ideas. 
 
The patch is at https://github.com/adventuresin9/9front-A64/compare/main...driusan:9front-A64:GenericArm64.patch 
 
I've: 
1. Tweaked the mkfile based on the imx8 kernel to pull in the generic code 
2. Deleted the now unnecessary files so that it uses the /sys/src/9/arm64 ones 
3. Updated the path for sysreg.h where it's included 
3. Updated dat.h to match the structures expected by the generic kernel 
4. Replaced mem.h with the one from imx8 and re-added the constants that adventurein9's kernel expects (after updating VUARTOUT to be relative to the lower VIRTIO). There did not seem to be anything A64 specific in the original. 
5. Compared the mmuenable and related code to imx8's, making it match 
where it differed. 
 
Does anyone have any suggestions? (There's a slight bug in the patch 
where KTZERO doesn't match between mem.h and the mkfile but I fixed 
that locally and it doesn't help.) 
 
I'm fairly sure its the memory mapping and not an incorrect memory 
address since PHYSCON used by the uart code is defined in terms of 
(VIRTIO+UART0) 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [9front] a64/arm64 mmu
  2025-01-26 23:37 [9front] a64/arm64 mmu Dave MacFarlane
@ 2025-01-28 22:01 ` Dave MacFarlane
  0 siblings, 0 replies; 2+ messages in thread
From: Dave MacFarlane @ 2025-01-28 22:01 UTC (permalink / raw)
  To: 9front

I believe I got it to work with the generic arm64 kernel code 
on the branch GenericArmTake2 in this patch (too big to include 
inline.) 
 
https://github.com/driusan/9front-A64/commit/5c9459d28f876eca40eb17ff6268e630de9b5093.patch 
 
I think the mmu stuff in mem.c could be reworked a little based on 
the imx8 implementation which seems a little more generic, but I'm 
able to boot this on my Pinephone. If anyone who has a Pinephone or other 
A64 board (sirjofri? adventuresin9?) could test it, it would be appreciated. 
 
- Dave 
 
Quoth Dave MacFarlane <driusan@driusan.net>: 
> I'm trying to update adventurein9's Allwinner A64 kernel to use the 
> generic arm64 code in 9front.  I think I've done most of the work, but 
> as far as I can tell there's a bug (in my changes, not in 9front) 
> where the virtual addresses aren't working after mmuenable in l.s. 
> WAVEs work before mmuenable.  Nothing goes to the uart after (either 
> VWAVE or prints).  I'm hoping someone who knows the code/architecture 
> better than I do might have ideas. 
>  
> The patch is at https://github.com/adventuresin9/9front-A64/compare/main...driusan:9front-A64:GenericArm64.patch 
>  
> I've: 
> 1. Tweaked the mkfile based on the imx8 kernel to pull in the generic code 
> 2. Deleted the now unnecessary files so that it uses the /sys/src/9/arm64 ones 
> 3. Updated the path for sysreg.h where it's included 
> 3. Updated dat.h to match the structures expected by the generic kernel 
> 4. Replaced mem.h with the one from imx8 and re-added the constants that adventurein9's kernel expects (after updating VUARTOUT to be relative to the lower VIRTIO). There did not seem to be anything A64 specific in the original. 
> 5. Compared the mmuenable and related code to imx8's, making it match 
> where it differed. 
>  
> Does anyone have any suggestions? (There's a slight bug in the patch 
> where KTZERO doesn't match between mem.h and the mkfile but I fixed 
> that locally and it doesn't help.) 
>  
> I'm fairly sure its the memory mapping and not an incorrect memory 
> address since PHYSCON used by the uart code is defined in terms of 
> (VIRTIO+UART0) 
>  

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-01-28 22:02 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-01-26 23:37 [9front] a64/arm64 mmu Dave MacFarlane
2025-01-28 22:01 ` Dave MacFarlane

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).