Code: Select all
mov w0,PERIPHERAL_BASE + GPIO_BASE // you load the value of w0 str w1,[x0,GPIO_GPFSEL4] // but then use x0 as an address ... what makes you think upper part of x0 is zero
Code: Select all
mov x0,PERIPHERAL_BASE + GPIO_BASE // load the value into x0
Code: Select all
.section .text.init_audio_jack, "ax", %progbits .balign 4 .globl init_audio_jack; .type init_audio_jack, %function init_audio_jack: mov x0,PERIPHERAL_BASE + GPIO_BASE mov w1,GPIO_FSEL0_ALT0 orr w1,w1,GPIO_FSEL5_ALT0 str w1,[x0,GPIO_GPFSEL4] // Set Clock mov w0,(PERIPHERAL_BASE + CM_BASE) & 0x0000FFFF mov w1,(PERIPHERAL_BASE + CM_BASE) & 0xFFFF0000 orr w0,w0,w1 mov w1,CM_PASSWORD orr w1,w1,0x2000 // Bits 0..11 Fractional Part Of Divisor = 0, Bits 12..23 Integer Part Of Divisor = 2 str w1,[x0,CM_PWMDIV] mov w1,CM_PASSWORD orr w1,w1,CM_ENAB orr w1,w1,CM_SRC_OSCILLATOR + CM_SRC_PLLCPER // Use 650MHz PLLC Clock str w1,[x0,CM_PWMCTL] // Set PWM mov w0,(PERIPHERAL_BASE + PWM_BASE) & 0x0000FFFF mov w1,(PERIPHERAL_BASE + PWM_BASE) & 0xFFFF0000 orr w0,w0,w1 mov w1,0x2C48 // Range = 13bit 44100Hz Mono str w1,[x0,PWM_RNG1] str w1,[x0,PWM_RNG2] mov w1,PWM_USEF2 + PWM_PWEN2 + PWM_USEF1 + PWM_PWEN1 + PWM_CLRF1 str w1,[x0,PWM_CTL] ret
Code: Select all
.section .text.play_audio, "ax", %progbits .balign 4 .globl play_audio; .type play_audio, %function play_audio: mov x0,PERIPHERAL_BASE + GPIO_BASE mov w0,(PERIPHERAL_BASE + PWM_BASE) & 0x0000FFFF mov w1,(PERIPHERAL_BASE + PWM_BASE) & 0xFFFF0000 orr w0,w0,w1 Loop: adr x1, _binary_src_audio_Interlude_bin_start // X1 = Sound Sample ldr w2, =_binary_src_audio_Interlude_bin_end and w2, w2, 0x0000FFFF // W2 = End Of Sound Sample ldr w3, =_binary_src_audio_Interlude_bin_end and w3, w3, 0xFFFF0000 orr w2,w2,w3 FIFO_Write: ldrh w3,[x1],2 // Write 2 Bytes To FIFO lsr w3,w3,3 // Convert 16bit To 13bit str w3,[x0,PWM_FIF1] // FIFO Address ldrh w3, [x1], 2 lsr w3, w3, 3 str w3, [x0, PWM_FIF1] FIFO_Wait: ldr w3,[x0,PWM_STA] tst w3,PWM_FULL1 // Test Bit 1 FIFO Full b.ne FIFO_Wait cmp w1,w2 // Check End Of Sound Sample b.ne FIFO_Write b Loop // Play Sample Again
Yes, the only way to truly understand what is happening is to work it out yourself, no matter how painful and tedious that may be .
A prefetch abort commonly relates to the CPU attempting to execute code in an area of memory that is either not marked as executable or not marked as readable, so as an example you may have a function pointer that points to something other than code and trying to call that function generates the prefetch abort.
If the exception happens immediately after enabling the MMU it would tend to indicate that something is incorrect with your page tables or MMU configuration. The next instruction after enabling the MMU will be fetched using the new configuration so if anything is wrong it will fail very quickly.
I will need to go back over it as was a few weeks ago to go thru it again .. I will pick it up in later post.LizardLad_1 wrote: ↑Fri Sep 28, 2018 8:32 amI know I have left this thread for a while however I would like to ask LdB I have fixed the half vector table however as you stated there were numerous errors that required correction before I go further. Would you please list these mistakes as apart from the dodgy interrupt table I thought my code was fairly solid.
What is the actual question ... why are you thinking the standard library couldn't be used?
Rather than answer your question directly what I did I want to give you a generic answer because there is no 1 solution. What you are basically trying to do communicate between the cores and this is where it gets tricky and there is no 1 idea or best solution, every solution has pros and cons.LizardLad_1 wrote: ↑Fri Sep 28, 2018 8:32 amThanks for fixing the coherency issues LdB. I was looking at your CoreExecute Function however I'm struggling to understand it. I know what it does and why it's required but I don't understand how. You also state in your comments it returns nothing, if it returns nothing your core execute fail is redundant because there isn't any return value visible to the calling function.
I haven't been able to use any system headers and I don't know how to use aarch64-*-gcc or ld to link libm to an executable for a bare metal environment. I would think you have to statically link libm but I can' t find the gnu standard libraries for aarch64 in the repositories. I am running Fedora 28 with the rpmfusion repositories enabled. It may be a compiler misconfiguration but I'm not sure. Thanks to any help you can provide.LdB wrote:What is the actual question ... why are you thinking the standard library couldn't be used?
Typically the only standard libraries you can't use straight up in baremetal are the ones that use memory allocation or file IO because there is no implementation. The memory system is usually trivial it can vary from 20 lines of code for a simple scheme to a few hundred for a full blown scheme. The file IO system which covers "stdio" etc is far more complex and mostly we implement what we need.
So if your fedora linux version is 32bit you would chooseBoth x86_64 Linux and Mingw32 (MS Windows compatible) host binaries are provided:
Users browsing this forum: No registered users and 3 guests