Re: libbsd ofwbus activate resources issue
I guess you have to define this in your : #define BSP_FDT_IS_SUPPORTED See also opt_fdt.h. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd ofwbus activate resources issue
Ok, and also need add the bsp_fdt_map_intr function in bspstart.c. right? Best Regards Sichen Zhao From: Sebastian Huber Sent: Monday, July 3, 2017 4:00:02 PM To: RTEMS Cc: Sichen Zhao Subject: Re: libbsd ofwbus activate resources issue I guess you have to define this in your : #define BSP_FDT_IS_SUPPORTED See also opt_fdt.h. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V interrupt vectoring
2017-07-03 7:43 GMT+02:00 Hesham Almatary : > On Mon, Jul 3, 2017 at 3:36 PM, Denis Obrezkov > wrote: > > 2017-07-03 4:59 GMT+02:00 Hesham Almatary : > >> > >> You can have a look at riscv-pk [1] as a RISC-V reference how to > >> handle interrupts. RTEMS-wise, you can look at or1k and ARM code and > >> how the platform-dependent interrupt handling code is linked to > >> platform-independent one. > >> > >> mcause value can be used as an index to a software vector table that you > >> set up. > >> > >> Why do you need software interrupts? GSoC-wise, I thought the plan was > >> to develop UART/Console driver (which doesn't need interrupts), and > >> use simulated ticker, as a first step. Then it will be easier to > >> debug/proceed from there with interrupt handling code. > > > > I thought, I have to implement an interrupt console driver. Okay, then I > am > > going to > > investigate a simulated ticker. > Yeah that can be done in later stages, for optimisation purposes. But > I think it's easier to implement it in polling mode first, just to get > things working, then you can easily move to interrupt-based > implementation. For example, if you've a polling console driver, you > can debug using printk, when developing the clock driver. Once you get > the clock driver working, you will have a more mature code for > interrupt handling, which enables you to very easily implement > interrupt-based UART driver. > > -- > > Regards, Denis Obrezkov > > > > -- > Hesham > It seems that vectored interrupts aren't available in FE310 SoC. Thus, I will work with mcause register. As for now, I want to: * add local interrupt handlers * add init code for counters initializtion (since we want to set up a baudrate) * implement a dummy clock driver * implement a polling uart * figure out how interrupts are handled in RTEMS * implement global interrupt handlers * implement a clock driver * implement an interrupt-mode uart driver. -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V interrupt vectoring
On Jul 3, 2017 11:49 AM, "Denis Obrezkov" wrote: 2017-07-03 7:43 GMT+02:00 Hesham Almatary : > On Mon, Jul 3, 2017 at 3:36 PM, Denis Obrezkov > wrote: > > 2017-07-03 4:59 GMT+02:00 Hesham Almatary : > >> > >> You can have a look at riscv-pk [1] as a RISC-V reference how to > >> handle interrupts. RTEMS-wise, you can look at or1k and ARM code and > >> how the platform-dependent interrupt handling code is linked to > >> platform-independent one. > >> > >> mcause value can be used as an index to a software vector table that you > >> set up. > >> > >> Why do you need software interrupts? GSoC-wise, I thought the plan was > >> to develop UART/Console driver (which doesn't need interrupts), and > >> use simulated ticker, as a first step. Then it will be easier to > >> debug/proceed from there with interrupt handling code. > > > > I thought, I have to implement an interrupt console driver. Okay, then I > am > > going to > > investigate a simulated ticker. > Yeah that can be done in later stages, for optimisation purposes. But > I think it's easier to implement it in polling mode first, just to get > things working, then you can easily move to interrupt-based > implementation. For example, if you've a polling console driver, you > can debug using printk, when developing the clock driver. Once you get > the clock driver working, you will have a more mature code for > interrupt handling, which enables you to very easily implement > interrupt-based UART driver. > > -- > > Regards, Denis Obrezkov > > > > -- > Hesham > It seems that vectored interrupts aren't available in FE310 SoC. Thus, I will work with mcause register. As for now, I want to: * add local interrupt handlers * add init code for counters initializtion (since we want to set up a baudrate) * implement a dummy clock driver This is easy and just requires one line in the BSP Makefile.am and an include in the .tcfg file to skip tests known to fail. See either the shsim or v850sim BSPs based on gdb for examples. It also lets you have all the tests running so you can add your target to RTEMS tester. :) * implement a polling uart Personally I would do this as soon as possible and get printk working. Very helpful and needed to run the tests with simulated clock tick with the polled driver. The counter is only needed for math on the baud rate I would guess. * figure out how interrupts are handled in RTEMS * implement global interrupt handlers * implement a clock driver * implement an interrupt-mode uart driver. -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V interrupt vectoring
2017-07-03 19:09 GMT+02:00 Joel Sherrill : > > > On Jul 3, 2017 11:49 AM, "Denis Obrezkov" wrote: > > 2017-07-03 7:43 GMT+02:00 Hesham Almatary : > >> On Mon, Jul 3, 2017 at 3:36 PM, Denis Obrezkov >> wrote: >> > 2017-07-03 4:59 GMT+02:00 Hesham Almatary : >> >> >> >> You can have a look at riscv-pk [1] as a RISC-V reference how to >> >> handle interrupts. RTEMS-wise, you can look at or1k and ARM code and >> >> how the platform-dependent interrupt handling code is linked to >> >> platform-independent one. >> >> >> >> mcause value can be used as an index to a software vector table that >> you >> >> set up. >> >> >> >> Why do you need software interrupts? GSoC-wise, I thought the plan was >> >> to develop UART/Console driver (which doesn't need interrupts), and >> >> use simulated ticker, as a first step. Then it will be easier to >> >> debug/proceed from there with interrupt handling code. >> > >> > I thought, I have to implement an interrupt console driver. Okay, then >> I am >> > going to >> > investigate a simulated ticker. >> Yeah that can be done in later stages, for optimisation purposes. But >> I think it's easier to implement it in polling mode first, just to get >> things working, then you can easily move to interrupt-based >> implementation. For example, if you've a polling console driver, you >> can debug using printk, when developing the clock driver. Once you get >> the clock driver working, you will have a more mature code for >> interrupt handling, which enables you to very easily implement >> interrupt-based UART driver. >> > -- >> > Regards, Denis Obrezkov >> >> >> >> -- >> Hesham >> > > It seems that vectored interrupts aren't available in FE310 SoC. > Thus, I will work with mcause register. > As for now, I want to: > * add local interrupt handlers > * add init code for counters initializtion (since we want to set up a > baudrate) > * implement a dummy clock driver > > > This is easy and just requires one line in the BSP Makefile.am and an > include in the .tcfg file to skip tests known to fail. See either the shsim > or v850sim BSPs based on gdb for examples. > > It also lets you have all the tests running so you can add your target to > RTEMS tester. :) > > * implement a polling uart > > > Personally I would do this as soon as possible and get printk working. > Very helpful and needed to run the tests with simulated clock tick with the > polled driver. > > The counter is only needed for math on the baud rate I would guess. > > * figure out how interrupts are handled in RTEMS > * implement global interrupt handlers > * implement a clock driver > * implement an interrupt-mode uart driver. > > > > -- > Regards, Denis Obrezkov > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > > > Ok, I will try to make a uart driver as soon as possible. I had some issues with dummy_clockdriver, I think there was a mistake, that an address of clock initialization function was wrong, so, I will investigate it tomorrow. Also, I have a problem, as I mentioned earlier, that the minimum example finished with the error ''INTERNAL_ERROR_THREAD_EXITTED". -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: LIBBSD
The MMU is disabled right now because I am tracking down a problem (not related to LIBBSD). I was going to turn it back on after I solve that issue. I'm using a 1ms tick. Kevin Kirspel Electrical Engineer - Sr. Staff Idexx Roswell 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 -Original Message- From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] Sent: Monday, July 03, 2017 1:47 AM To: Kirspel, Kevin ; devel@rtems.org Subject: Re: LIBBSD On 30/06/17 20:08, Kirspel, Kevin wrote: > Case #2: Enable the RTEMS callout timer but do not call "callout_process()" > (the timer service routine just resets the timer and quits) . > IDLE Task CPUUSE: 93.144% > TIME Task CPUUSE: 6.282% In this case you have some low-level problem on your target. Is the cache enabled and properly set up in the MMU? How many ticks per second do you use? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V interrupt vectoring
On Jul 3, 2017 12:45 PM, "Denis Obrezkov" wrote: 2017-07-03 19:09 GMT+02:00 Joel Sherrill : > > > On Jul 3, 2017 11:49 AM, "Denis Obrezkov" wrote: > > 2017-07-03 7:43 GMT+02:00 Hesham Almatary : > >> On Mon, Jul 3, 2017 at 3:36 PM, Denis Obrezkov >> wrote: >> > 2017-07-03 4:59 GMT+02:00 Hesham Almatary : >> >> >> >> You can have a look at riscv-pk [1] as a RISC-V reference how to >> >> handle interrupts. RTEMS-wise, you can look at or1k and ARM code and >> >> how the platform-dependent interrupt handling code is linked to >> >> platform-independent one. >> >> >> >> mcause value can be used as an index to a software vector table that >> you >> >> set up. >> >> >> >> Why do you need software interrupts? GSoC-wise, I thought the plan was >> >> to develop UART/Console driver (which doesn't need interrupts), and >> >> use simulated ticker, as a first step. Then it will be easier to >> >> debug/proceed from there with interrupt handling code. >> > >> > I thought, I have to implement an interrupt console driver. Okay, then >> I am >> > going to >> > investigate a simulated ticker. >> Yeah that can be done in later stages, for optimisation purposes. But >> I think it's easier to implement it in polling mode first, just to get >> things working, then you can easily move to interrupt-based >> implementation. For example, if you've a polling console driver, you >> can debug using printk, when developing the clock driver. Once you get >> the clock driver working, you will have a more mature code for >> interrupt handling, which enables you to very easily implement >> interrupt-based UART driver. >> > -- >> > Regards, Denis Obrezkov >> >> >> >> -- >> Hesham >> > > It seems that vectored interrupts aren't available in FE310 SoC. > Thus, I will work with mcause register. > As for now, I want to: > * add local interrupt handlers > * add init code for counters initializtion (since we want to set up a > baudrate) > * implement a dummy clock driver > > > This is easy and just requires one line in the BSP Makefile.am and an > include in the .tcfg file to skip tests known to fail. See either the shsim > or v850sim BSPs based on gdb for examples. > > It also lets you have all the tests running so you can add your target to > RTEMS tester. :) > > * implement a polling uart > > > Personally I would do this as soon as possible and get printk working. > Very helpful and needed to run the tests with simulated clock tick with the > polled driver. > > The counter is only needed for math on the baud rate I would guess. > > * figure out how interrupts are handled in RTEMS > * implement global interrupt handlers > * implement a clock driver > * implement an interrupt-mode uart driver. > > > > -- > Regards, Denis Obrezkov > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > > > Ok, I will try to make a uart driver as soon as possible. I had some issues with dummy_clockdriver, I think there was a mistake, that an address of clock initialization function was wrong, so, I will investigate it tomorrow. Also, I have a problem, as I mentioned earlier, that the minimum example finished with the error ''INTERNAL_ERROR_THREAD_EXITTED". That is probably the correct behavior. It is not intended to be executed. It is just an example of how to strip down a configuration to get a program running. The Init thread is completely empty as I recall so it would return and fail like this. I would move on to hello. Use the existing sim clock driver and the polled console driver framework until this much all works. See how the two BSPs I mentioned earlier do things. That will minimize the amount of code you have to write until you can focus on the interrupts. Also.. hello world is the first step. Usually adding a delay/sleep call to that or using ticker/sp01 is how to debug a clock driver and interrupt driven console driver. -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix GDB build on ArchLinux
On 02/07/2017 02:01, andreas.koe...@st.oth-regensburg.de wrote: > From: Andreas Kölbl > > Archlinux provides both, libguile v2.0 and v2.2. GDB states in > configuration its compatibility with both versions of libguile which is > false. The SCM_port interface of libguile was removed in v2.2 and > therefore breaks GDB as a user. > > RTEMS does not use libguile and therefore it can be compiled without > support. > > https://sourceware.org/bugzilla/show_bug.cgi?id=21104 > > Close #3054. Pushed. Thank you. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
