If anyone is interested, I put something related on supporting the UART1 on
the beaglebone here:
http://julien.gunnm.org/geek/sel4/beaglebone%20black/2016/06/15/beaglebone-black-sel4-uart1/

On Mon, Jun 13, 2016 at 11:59 AM, Julien Delange <[email protected]>
wrote:

> Hi all,
>
> I tried the platform_init or adding the instructions in uboot but still
> have some issues at execution (see below).
>
> My code is the following, mostly inspired by the code in the platsupport
> lib. The uartmem pointer is the memory address configured in the camkes
> assembly (which is configured as follow: drv.mem_attributes       =
> "0x48022000:0x1000";). Here, I am just trying to put an 'h' on the uart.
>
> Does anyone have a code sample that uses the UART1 of the beaglebone they
> could share so that I could investigate what I doing wrong? That might
> help, it should be a stupid initialization error or something closely
> related.
>
> Thanks!
>
>
> int uart_putchar(int c)
> {
>     while (!(*REG_PTR(uartmem, LSR) & LSR_TXFIFOE)) {
>         continue;
>     }
>     *REG_PTR(uartmem, THR) = c;
>
>     return c;
> }
>
> int run(void)
> {
> int val;
> printf("run\n");
>   while (1)
>   {
> activator_wait();
> user_ping_spg ((*data_sink) );
> uart_putchar ('h');
> val = uart_getchar();
>
>         printf ("UART= %d\n", val);
>
>    }
>    return 0;
> }
>
>
>
>
> Caught cap fault in send phase at address 0x0
> while trying to handle:
> vm fault on data at address 0x314000 with status 0x7
> in thread 0xf237d900 "Cons_PingMe(1)" at address 0x1001a8
> With stack:
> 0x232cb0: 0x20f19c
> 0x232cb4: 0x1
> 0x232cb8: 0x20ed90
> 0x232cbc: 0x100ebc
> 0x232cc0: 0x1
> 0x232cc4: 0x0
> 0x232cc8: 0x1
> 0x232ccc: 0x0
> 0x232cd0: 0x0
> 0x232cd4: 0x0
> 0x232cd8: 0x0
> 0x232cdc: 0x0
> 0x232ce0: 0x0
> 0x232ce4: 0x0
> 0x232ce8: 0x0
> 0x232cec: 0x0
>
>
>
> On Sat, Jun 11, 2016 at 7:40 AM, Jeff Hieb <[email protected]>
> wrote:
>
>> I have tried making mux changes in CAmkES (though I can't say
>> exhaustively) and what I experienced was that it didn't work.  My reading
>> of the AMX335x manual is that the processor has to be in the highest
>> privilege mode to changes to the control module registers.  I added the
>> control module memory page to hardware.c, but when I wrote to the registers
>> they didn't change?  It is however certainly possible that I did something
>> wrong.  Now that I have the driver working, I should go back and try again.
>>
>> I just tried modifying platform_init and that seems to work. Thanks!
>>
>>
>> Jeff
>>
>>
>>
>> Jeffrey L. Hieb
>> Department of Engineering Fundamentals
>> University of Louisville
>> Louisville Kentucky 40292
>> (502) 852 0465
>>
>> On 6/10/2016 8:19 PM, Alexander Kroh wrote:
>>
>>> The solution that we use is to create a "mux" CAmkES component to
>>> configures the pins. Dependent components then send an RPC to this
>>> component, which returns only once the MUX configuration has completed.
>>> Of course, it is likely that the mux device memory will also need to be
>>> exported as a frame cap for this platform via changes to
>>> kernel/src/plat/am335x/machine/hardware.c
>>>
>>> Alternatively, one could modify void platform_init(void){} within the
>>> elfloader-tool to include the manual manipulation:
>>> *(volatile uint32_t*)0x44E10980 = 0x30
>>> *(volatile uint32_t*)0x44E10984 = 0x00
>>>
>>>
>>>   - AlexK
>>>
>>> ________________________________________
>>> From: Devel [[email protected]] on behalf of Jeff Hieb [
>>> [email protected]]
>>> Sent: Saturday, 11 June 2016 09:06
>>> To: [email protected]
>>> Subject: Re: [seL4] Beaglebone black/CAmkES issue
>>>
>>> Julien
>>>
>>> I am using UART1 (and 2 and 4) on BBB with Camkes.
>>>
>>> I think you need to set the pin mux on the board.  Linux does this with
>>> something called device tree overlays (
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.adafruit.com_introduction-2Dto-2Dthe-2Dbeaglebone-2Dblack-2Ddevice-2Dtree_device-2Dtree-2Doverlays&d=AwIFAg&c=SgMrq23dbjbGX6e0ZsSHgEZX6A4IAf1SO3AJ2bNrHlk&r=vxDfYJYhOaaufTHzA3yxVVn--9Yf3Ig5TrUiTFGL8pc&m=C5a3iZw4GmcNm0Rx6PhN12aOif1P10puZ0_iN0s4Oog&s=4HJlLN4fCMrxPH6GfZjR3F931pN1ZmbmYLMA83yf6w8&e=
>>> ).
>>>
>>>
>>>
>>> Sel4 and Camkes don't provide away to  set the mux for the pins (that I
>>> am aware of), So you have do it before booting the kernel.
>>>
>>> I haven't found a particularly clean way to do this yet.  Currently I am
>>> just using UBoot to set the pin muxes.
>>>
>>> Before booting your kernel, at the UBoot command line try these two
>>> lines:
>>>
>>> mw.l 0x44E10980 0x30
>>>
>>> mw.l 0x44E10984 0x00
>>>
>>>
>>> This should correctly turn on the UART 1 Rx and Tx lines.
>>>
>>>
>>> Also.  I you want to turn on the fifos, the reference manual seems to
>>> gloss over part of how to do that.  Here is my code to
>>>
>>> // config to fifo with interrupt but no DMA
>>>      *UART_REG(LCR) = 0xBF;
>>>      *UART_REG(EFR) = 0x10;
>>>      *UART_REG(LCR) = 0x80;
>>>      *UART_REG(SCR) = 0x01;
>>>      *UART_REG(MCR) = 0x40;
>>>      *UART_REG(TLR) = 0x11;
>>>
>>>      *UART_REG(MCR) = 0x00;
>>>      *UART_REG(FCR) = 0x07;
>>>
>>>
>>>
>>>
>>> Jeffrey L. Hieb
>>> Department of Engineering Fundamentals
>>> University of Louisville
>>> Louisville Kentucky 40292
>>> (502) 852 0465
>>>
>>> On 6/10/2016 3:05 PM, Julien Delange wrote:
>>> Yep, I did this. The code boots correctly and the device is recognized.
>>> The serial is still not working, I assume this is a matter of code right
>>> now.
>>>
>>> Thanks!
>>>
>>> Julien,
>>>
>>> On Fri, Jun 10, 2016 at 2:57 PM, Tim Newsham <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> I think you need to add a line in
>>> kernel/src/plat/am335x/machine/hardware.c
>>> for this.
>>>
>>> On Fri, Jun 10, 2016 at 8:37 AM, Julien Delange <<mailto:
>>> [email protected]>[email protected]<mailto:
>>> [email protected]>> wrote:
>>> I am using the second serial interface of the beaglebone black.
>>> According to the source code (in
>>> libsel4platsupport/plat_include/am335x/sel4platsupport/plat/hw/soc_AM335x.h),
>>> the address is 0x48022000). The following line is found in the source
>>>
>>> #define SOC_UART_1_REGS                      (0x48022000)
>>>
>>> So, in CAmkES, I configure the hardware component that represents the
>>> serial hardware component with the following attributes:
>>>
>>> drv.mem_attributes       = "0x48022000:0x1000";
>>>
>>> The application compiles fine. However, when launching the image on the
>>> target, I have the following issue. Any idea about how to solve this? Does
>>> anybody successfully used UART1 on the beaglebone black? Or have any
>>> idea/suggestion to investigate?
>>>
>>> Thanks.
>>>
>>> Julien.
>>>
>>>
>>> Creating object conn1_frame__timer_0 in slot 728, from untyped 29b...
>>>   device frame, paddr = 0x48040000, size = 12 bits
>>> Creating object conn2_frame__Cons_PingMe_0 in slot 729, from untyped
>>> 29b...
>>>   device frame, paddr = 0x48022000, size = 12 bits
>>>
>>> capDL-loader :: << Error: Failed to find device frame at paddr =
>>> 0x48022000
>>>   >>
>>> Ignoring call to sys_rt_sigprocmask
>>> Ignoring call to sys_gettid
>>> sys_tkill assuming self kill
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> [email protected]<mailto:[email protected]>
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__sel4.systems_lists_listinfo_devel&d=AwIFAg&c=SgMrq23dbjbGX6e0ZsSHgEZX6A4IAf1SO3AJ2bNrHlk&r=vxDfYJYhOaaufTHzA3yxVVn--9Yf3Ig5TrUiTFGL8pc&m=C5a3iZw4GmcNm0Rx6PhN12aOif1P10puZ0_iN0s4Oog&s=y6EZdBAh-G5iK0sSTSL0dG0H7TDfs_aUkGM8mqU1uNs&e=
>>> <
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__sel4.systems_lists_listinfo_devel&d=AwMFaQ&c=SgMrq23dbjbGX6e0ZsSHgEZX6A4IAf1SO3AJ2bNrHlk&r=vxDfYJYhOaaufTHzA3yxVVn--9Yf3Ig5TrUiTFGL8pc&m=MGwV9yE3Lj-QU0UntmkIzrms26F8fDzA5Qzvk9IrTS0&s=DaDr7rfeonVlo85YWw34Fz637peI234w5Pt-qM3RfrY&e=
>>> >
>>>
>>>
>>>
>>>
>>> --
>>> Tim Newsham | <
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.thenewsh.com_-7Enewsham&d=AwMFaQ&c=SgMrq23dbjbGX6e0ZsSHgEZX6A4IAf1SO3AJ2bNrHlk&r=vxDfYJYhOaaufTHzA3yxVVn--9Yf3Ig5TrUiTFGL8pc&m=MGwV9yE3Lj-QU0UntmkIzrms26F8fDzA5Qzvk9IrTS0&s=Cjc7dPZwf0158fR2amZ2xCr_dDFoLAcPjjHnVtmNCZk&e=>
>>> www.thenewsh.com/~newsham<
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.thenewsh.com_-7Enewsham&d=AwIFAg&c=SgMrq23dbjbGX6e0ZsSHgEZX6A4IAf1SO3AJ2bNrHlk&r=vxDfYJYhOaaufTHzA3yxVVn--9Yf3Ig5TrUiTFGL8pc&m=C5a3iZw4GmcNm0Rx6PhN12aOif1P10puZ0_iN0s4Oog&s=R5sWEaGJpqI9Ii5meYEuozYB5CG7BnpZS7jwvTWhXkE&e=
>>> > | @newshtwit | thenewsh.blogspot.com<
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thenewsh.blogspot.com&d=AwMFaQ&c=SgMrq23dbjbGX6e0ZsSHgEZX6A4IAf1SO3AJ2bNrHlk&r=vxDfYJYhOaaufTHzA3yxVVn--9Yf3Ig5TrUiTFGL8pc&m=MGwV9yE3Lj-QU0UntmkIzrms26F8fDzA5Qzvk9IrTS0&s=DIUb0PJN4Ew4zS3H66GvnNKjVk9AjcRLJtgvpcF_vm8&e=
>>> >
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> [email protected]<mailto:[email protected]>
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__sel4.systems_lists_listinfo_devel&d=AwICAg&c=SgMrq23dbjbGX6e0ZsSHgEZX6A4IAf1SO3AJ2bNrHlk&r=vxDfYJYhOaaufTHzA3yxVVn--9Yf3Ig5TrUiTFGL8pc&m=MGwV9yE3Lj-QU0UntmkIzrms26F8fDzA5Qzvk9IrTS0&s=DaDr7rfeonVlo85YWw34Fz637peI234w5Pt-qM3RfrY&e=
>>>
>>>
>>> ________________________________
>>>
>>> The information in this e-mail may be confidential and subject to legal
>>> professional privilege and/or copyright. National ICT Australia Limited
>>> accepts no liability for any damage caused by this email or its attachments.
>>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> [email protected]
>> https://sel4.systems/lists/listinfo/devel
>>
>
>
_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel

Reply via email to