Re: Git Master Freeze for 4.11
With the fix for the POSIX thread join (it took only three years to fix the bug) I am done with 4.11. Everything else can wait after the branch. For the tools I propose to use GCC 4.9.3 (should get released soon) and the next Newlib snapshot. On 24/04/15 02:39, Chris Johns wrote: Hello, I would like to propose we freeze the master branch in git and only regressions are committed. Joel is intending to branch on Monday his time if everything is ok but we need time to test before the branch is made. If there are any objections please raise them otherwise I will assume master is frozen. Lets assume this is the case for the rtems, rtems-source-builder and rtems-tools repos. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- 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: Git Master Freeze for 4.11
On 24/04/2015 5:02 pm, Sebastian Huber wrote: > With the fix for the POSIX thread join (it took only three years to fix > the bug) I am done with 4.11. Everything else can wait after the branch. Excellent and yes. > > For the tools I propose to use GCC 4.9.3 (should get released soon) and > the next Newlib snapshot. > Snapshot name ? Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Git Master Freeze for 4.11
On 24/04/15 09:11, Chris Johns wrote: >For the tools I propose to use GCC 4.9.3 (should get released soon) and >the next Newlib snapshot. > Snapshot name ? Its not available yet, but we are close to the end of the month. -- 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: Git Master Freeze for 4.11
On Fri, Apr 24, 2015 at 3:13 AM, Sebastian Huber wrote: > > > On 24/04/15 09:11, Chris Johns wrote: >>> >>> >For the tools I propose to use GCC 4.9.3 (should get released soon) and >>> >the next Newlib snapshot. >>> > >> >> Snapshot name ? > > > Its not available yet, but we are close to the end of the month. > We can ping Jeff if it is an appropriate amount of time since the last one, and newlib has everything we need in it. > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] posix: Use right thread dispatch disable function
Why do we have these two functions with similar names and commented to have the same functionality? If one is for SMP and the other for UP, should they be unified or is there a good reason to have separate functions? On Fri, Apr 24, 2015 at 2:42 AM, Sebastian Huber wrote: > Module:rtems > Branch:master > Commit:d83127e9bd39c1a8c7ef51aa4d9034b06a2bd115 > Changeset: > http://git.rtems.org/rtems/commit/?id=d83127e9bd39c1a8c7ef51aa4d9034b06a2bd115 > > Author:Sebastian Huber > Date: Fri Apr 24 08:36:33 2015 +0200 > > posix: Use right thread dispatch disable function > > --- > > cpukit/posix/src/mutexlocksupp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/cpukit/posix/src/mutexlocksupp.c > b/cpukit/posix/src/mutexlocksupp.c > index 92c6556..9b20f58 100644 > --- a/cpukit/posix/src/mutexlocksupp.c > +++ b/cpukit/posix/src/mutexlocksupp.c > @@ -55,7 +55,7 @@ int _POSIX_Mutex_Lock_support( > > case OBJECTS_LOCAL: > #if defined(RTEMS_SMP) > - _Thread_Dispatch_disable(); > + _Thread_Disable_dispatch(); > #endif >executing = _Thread_Executing; >_CORE_mutex_Seize( > > ___ > vc mailing list > v...@rtems.org > http://lists.rtems.org/mailman/listinfo/vc ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
4.11 BLOCKER - Multiple BSPs fail to build - cache changes?
Hi Multiple BSPs failed to build in my overnight sweep. All bfin and or1k BSPs plus 18 m68k failed with this: ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:340:1: error: static declaration of '_CPU_cache_invalidate_instruction_range' follows non-static declaration _CPU_cache_invalidate_instruction_range( ^ In file included from ../../../../../../../rtems/c/src/lib/libcpu/m68k/shared/cache/cache_.h:37:0, from ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:39: ../../../../.././mcf5329/lib/include/libcpu/cache.h:30:6: note: previous declaration of '_CPU_cache_invalidate_instruction_range' was here void _CPU_cache_invalidate_instruction_range(const void *i_addr, size_t n_bytes); ^ bfin/bf537Stamp, or1k/or1k_generic, and m68k/mvme136 should be sufficient to reproduce and fix the problem. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Beagle BSP Improvements (GPIO driver)
All, Big improvement. The video shows that the bit logic for setting & clearing is likely sound - for the first byte at least ;-). Good test. My comments about the code are - gpio_select_pin write a whole 0 byte instead of updating a single bit, as we talked about on IRC - gedare's suggestion to use a single function to update bits in registers is good - you can use this for gpio_select_pin, gpio_set and gpio_clear. - i don't like the addition of arm_delay() in the bsp code. if it's not bsp-specific (and it isn't), it shouldn't be there. - the AM335X-specific code isn't made conditional My comment about the API that is: I don't like it that hardware-specific info (GPIO base registers) is somewhat external to the BSP. To my mind, the application should only deal with bank numbers and pin numbers. So either we need 128 more #defines of the GPIO_PIN struct in the current vein, meaning inline struct initializers are passed around (ew) and we rely on quite a lot of app discipline to keep it clean (ew); or we need an api like gpio_config(&gpio_conf); /* retrieve number of gpio banks & pins per bank, possibly more info */ gpio_select_pin(&gpio_pin, bank_number, pin_number, DIGITAL_OUTPUT); /* fill in gpio_pin struct to use this pin */ gpio_set(&gpio_pin); gpio_clear(&gpio_pin); gpio_release_pin(&gpio_pin); /* allows repurposing this pin */ this way the configuring of gpio_pin (containing hardware-specific info) is more internal to the BSP, and the app would have to actively subvert the api (look in the gpio_pin struct) and is less prone to be written badly by accident (hardcoding hardware addresses in the app). Thoughts anyone? On Thu, Apr 23, 2015 at 8:35 PM, Ketul Shah wrote: > Hi all, > > Ben Gras thanks for your comments and encouragement for merging with > mainline as a motivation for me. > > I worked and redeveloped code for gpio driver also tried to approach towards > common api. I tried to address most of the comments. Herewith I attached my > patch. Would be happy to hear comments on that. > > You can also find out my gist or commit on https://github.com/RTEMS/rtems . > I have been updating my work on https://github.com/ketul93/RTEMS-on-BBB. > > Live demo of the updated code is found on :- https://youtu.be/bXurelOA3i0 > > Thanks. > > Regards, > ketul > > > On 20 April 2015 at 19:50, Ben Gras wrote: >> >> All, >> >> Good contribution, thank you. >> >> For GSOC, this is good proof of being able to progress and get >> something real working based on documentation. Great! >> >> If you want this merged with mainline - which I fully encourage! - >> then I suggest the following should be added to/changed first: >> >> - make the code that uses AM335X (beaglebone) specific registers, >> AM335X-specific :) i.e. add #if IS_AM335X around code that should >> only execute there. this BSP can be compiled for 2 different SOCs. >> - let it control all GPIO's - there are 4 banks of 32 each on the >> AM335x, but you only let the user control GPIO1. there should be a >> clean interface to control them all (clean means mostly: without >> duplicating code) >> - as Gedare mentioned on IRC, copy the RPi API. this is a first >> (second?) step to finding a generalized GPIO API. >> - don't add beagleboard.h, but add your definitions to >> libcpu/arm/shared/include/am335x.h >> - the code should use a more consistent indenting style, and make >> variable names more descriptive than 'tmp'. >> - don't leave the configure changes in like in acinclude.m4 >> >> bonus: >> - add DM3730 (beagleboard) support. >> >> Good luck! >> >> >> On Fri, Apr 17, 2015 at 7:51 PM, Ketul Shah >> wrote: >> > Hello, >> > >> > I have proposed in GSoC on Beagle BSP Improvements. As starting I >> > started >> > working for gpio driver development . At this stage I am able to >> > demonstrate >> > USR LEDs pattern. >> > >> > Videos of that can be found here on YouTube. >> > https://youtu.be/B3mSsfo-PAQ & >> > https://youtu.be/M1aKpOhUvv4. >> > >> > Herewith I have attached patch.txt file. Alternatively you can have >> > https://gist.github.com/ketul93/2e0d2c4b8b586be62e1d that includes the >> > newly >> > added files code. I would be happy to hear your reviews and changes on >> > my >> > work. >> > >> > And also I have been updating my work on >> > https://github.com/ketul93/RTEMS-on-BBB repo. >> > >> > It would be great to have your comments on my proposal. >> > >> > Thanks and regards, >> > ketul >> > >> > ___ >> > 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: 4.11 BLOCKER - Multiple BSPs fail to build - cache changes?
Hi, I believe this commit is the one which broke it [1], I'm going to discard the usage of the shared cache_manager.c file and provide or1k with private stubs. [1] https://github.com/RTEMS/rtems/commit/26c142e5ad4a63ad42baa17159c1821afe473a00 On Fri, Apr 24, 2015 at 5:16 PM, Joel Sherrill wrote: > Hi > > Multiple BSPs failed to build in my overnight sweep. All > bfin and or1k BSPs plus 18 m68k failed with this: > > ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:340:1: > error: static declaration of '_CPU_cache_invalidate_instruction_range' > follows non-static declaration > _CPU_cache_invalidate_instruction_range( > ^ > In file included from > ../../../../../../../rtems/c/src/lib/libcpu/m68k/shared/cache/cache_.h:37:0, > from > ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:39: > ../../../../.././mcf5329/lib/include/libcpu/cache.h:30:6: note: previous > declaration of '_CPU_cache_invalidate_instruction_range' was here > void _CPU_cache_invalidate_instruction_range(const void *i_addr, size_t > n_bytes); > ^ > > bfin/bf537Stamp, or1k/or1k_generic, and m68k/mvme136 should > be sufficient to reproduce and fix the problem. > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 BLOCKER - Multiple BSPs fail to build - cache changes?
Wouldn't it be better to fix the or1k function declarations unless there is going to be or1k-specific implementation provided? On Fri, Apr 24, 2015 at 1:07 PM, Hesham ALMatary wrote: > Hi, > > I believe this commit is the one which broke it [1], I'm going to > discard the usage of the shared cache_manager.c file and provide or1k > with private stubs. > > [1] > https://github.com/RTEMS/rtems/commit/26c142e5ad4a63ad42baa17159c1821afe473a00 > > On Fri, Apr 24, 2015 at 5:16 PM, Joel Sherrill > wrote: >> Hi >> >> Multiple BSPs failed to build in my overnight sweep. All >> bfin and or1k BSPs plus 18 m68k failed with this: >> >> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:340:1: >> error: static declaration of '_CPU_cache_invalidate_instruction_range' >> follows non-static declaration >> _CPU_cache_invalidate_instruction_range( >> ^ >> In file included from >> ../../../../../../../rtems/c/src/lib/libcpu/m68k/shared/cache/cache_.h:37:0, >> from >> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:39: >> ../../../../.././mcf5329/lib/include/libcpu/cache.h:30:6: note: previous >> declaration of '_CPU_cache_invalidate_instruction_range' was here >> void _CPU_cache_invalidate_instruction_range(const void *i_addr, size_t >> n_bytes); >> ^ >> >> bfin/bf537Stamp, or1k/or1k_generic, and m68k/mvme136 should >> be sufficient to reproduce and fix the problem. >> >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@oarcorp.comOn-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available(256) 722-9985 >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > > > -- > Hesham > ___ > 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: [PATCH] Beagle BSP Improvements (GPIO driver)
On 4/24/2015 11:48 AM, Ben Gras wrote: > All, > > Big improvement. The video shows that the bit logic for setting & > clearing is likely sound - for the first byte at least ;-). Good test. > > My comments about the code are > - gpio_select_pin write a whole 0 byte instead of updating a single > bit, as we talked about on IRC > - gedare's suggestion to use a single function to update bits in > registers is good - you can use this for gpio_select_pin, gpio_set and > gpio_clear. > - i don't like the addition of arm_delay() in the bsp code. if it's > not bsp-specific (and it isn't), it shouldn't be there. > - the AM335X-specific code isn't made conditional > > My comment about the API that is: > > I don't like it that hardware-specific info (GPIO base registers) is > somewhat external to the BSP. To my mind, the application should only > deal with bank numbers and pin numbers. So either we need 128 more > #defines of the GPIO_PIN struct in the current vein, meaning inline > struct initializers are passed around (ew) and we rely on quite a lot > of app discipline to keep it clean (ew); or we need an api like > > gpio_config(&gpio_conf); /* retrieve number of gpio banks & pins per > bank, possibly more info */ > gpio_select_pin(&gpio_pin, bank_number, pin_number, DIGITAL_OUTPUT); > /* fill in gpio_pin struct to use this pin */ > gpio_set(&gpio_pin); > gpio_clear(&gpio_pin); > gpio_release_pin(&gpio_pin); /* allows repurposing this pin */ > > this way the configuring of gpio_pin (containing hardware-specific > info) is more internal to the BSP, and the app would have to actively > subvert the api (look in the gpio_pin struct) and is less prone to be > written badly by accident (hardcoding hardware addresses in the app). > > Thoughts anyone? We need a generic rtems_gpio_XXX API set. That was what I took at initial shot at with the multio code. I started mentally with separate APIs completely for analog and discretes but since I was handed a baseboard with 32 bit GPIO pins and an add-on board with ADCs, DACs, and more GPIOs, I needed a unified interface. The collection of various IO types on a board is common. The application should be completely independent of the BSP. My app will have to know that "the red warning light" is bank 1, pin 3 on board X and bank 7, pin 12 when using another board. That is an application issue. The BSP/system configuration has to present a single API to the app. Remember that the system integrator may add boards. So the "system configuration" may include things not on the baseboard. The SIGAda 2009 presentation I sent privately a few days ago had that configuration and was what I did the API work I did for. > > > On Thu, Apr 23, 2015 at 8:35 PM, Ketul Shah wrote: >> Hi all, >> >> Ben Gras thanks for your comments and encouragement for merging with >> mainline as a motivation for me. >> >> I worked and redeveloped code for gpio driver also tried to approach towards >> common api. I tried to address most of the comments. Herewith I attached my >> patch. Would be happy to hear comments on that. >> >> You can also find out my gist or commit on https://github.com/RTEMS/rtems . >> I have been updating my work on https://github.com/ketul93/RTEMS-on-BBB. >> >> Live demo of the updated code is found on :- https://youtu.be/bXurelOA3i0 >> >> Thanks. >> >> Regards, >> ketul >> >> >> On 20 April 2015 at 19:50, Ben Gras wrote: >>> All, >>> >>> Good contribution, thank you. >>> >>> For GSOC, this is good proof of being able to progress and get >>> something real working based on documentation. Great! >>> >>> If you want this merged with mainline - which I fully encourage! - >>> then I suggest the following should be added to/changed first: >>> >>> - make the code that uses AM335X (beaglebone) specific registers, >>> AM335X-specific :) i.e. add #if IS_AM335X around code that should >>> only execute there. this BSP can be compiled for 2 different SOCs. >>> - let it control all GPIO's - there are 4 banks of 32 each on the >>> AM335x, but you only let the user control GPIO1. there should be a >>> clean interface to control them all (clean means mostly: without >>> duplicating code) >>> - as Gedare mentioned on IRC, copy the RPi API. this is a first >>> (second?) step to finding a generalized GPIO API. >>> - don't add beagleboard.h, but add your definitions to >>> libcpu/arm/shared/include/am335x.h >>> - the code should use a more consistent indenting style, and make >>> variable names more descriptive than 'tmp'. >>> - don't leave the configure changes in like in acinclude.m4 >>> >>> bonus: >>> - add DM3730 (beagleboard) support. >>> >>> Good luck! >>> >>> >>> On Fri, Apr 17, 2015 at 7:51 PM, Ketul Shah >>> wrote: Hello, I have proposed in GSoC on Beagle BSP Improvements. As starting I started working for gpio driver development . At this stage I am able to demonstrate USR LEDs pattern. Videos of that can be found here on YouTub
Re: 4.11 BLOCKER - Multiple BSPs fail to build - cache changes?
On 4/24/2015 12:07 PM, Hesham ALMatary wrote: > Hi, > > I believe this commit is the one which broke it [1], I'm going to > discard the usage of the shared cache_manager.c file and provide or1k > with private stubs. > > [1] > https://github.com/RTEMS/rtems/commit/26c142e5ad4a63ad42baa17159c1821afe473a00 This also broke two other architectures. Fixing it for the or1k is not sufficient. Please either provide proper caching for the or1k or fix it in a way that fixes all three architectures. > On Fri, Apr 24, 2015 at 5:16 PM, Joel Sherrill > wrote: >> Hi >> >> Multiple BSPs failed to build in my overnight sweep. All >> bfin and or1k BSPs plus 18 m68k failed with this: >> >> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:340:1: >> error: static declaration of '_CPU_cache_invalidate_instruction_range' >> follows non-static declaration >> _CPU_cache_invalidate_instruction_range( >> ^ >> In file included from >> ../../../../../../../rtems/c/src/lib/libcpu/m68k/shared/cache/cache_.h:37:0, >> from >> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:39: >> ../../../../.././mcf5329/lib/include/libcpu/cache.h:30:6: note: previous >> declaration of '_CPU_cache_invalidate_instruction_range' was here >> void _CPU_cache_invalidate_instruction_range(const void *i_addr, size_t >> n_bytes); >> ^ >> >> bfin/bf537Stamp, or1k/or1k_generic, and m68k/mvme136 should >> be sufficient to reproduce and fix the problem. >> >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@oarcorp.comOn-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available(256) 722-9985 >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 BLOCKER - Multiple BSPs fail to build - cache changes?
Gedare, The corresponding function declaration and implementation are included from libcpu/shared. There are two solutions to fix this for the all broken BSPs: 1- Get rid of _CPU_cache_invalidate_instruction_range declaration at libcpu/shared/include/cache.h, since this functions is already called at cache_manager.c 2- Get rid of the static keyword at cache_manager.c. On Fri, Apr 24, 2015 at 6:13 PM, Joel Sherrill wrote: > > > On 4/24/2015 12:07 PM, Hesham ALMatary wrote: >> Hi, >> >> I believe this commit is the one which broke it [1], I'm going to >> discard the usage of the shared cache_manager.c file and provide or1k >> with private stubs. >> >> [1] >> https://github.com/RTEMS/rtems/commit/26c142e5ad4a63ad42baa17159c1821afe473a00 > This also broke two other architectures. Fixing it for the or1k is not > sufficient. > Please either provide proper caching for the or1k or fix it in a way that > fixes all three architectures. >> On Fri, Apr 24, 2015 at 5:16 PM, Joel Sherrill >> wrote: >>> Hi >>> >>> Multiple BSPs failed to build in my overnight sweep. All >>> bfin and or1k BSPs plus 18 m68k failed with this: >>> >>> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:340:1: >>> error: static declaration of '_CPU_cache_invalidate_instruction_range' >>> follows non-static declaration >>> _CPU_cache_invalidate_instruction_range( >>> ^ >>> In file included from >>> ../../../../../../../rtems/c/src/lib/libcpu/m68k/shared/cache/cache_.h:37:0, >>> from >>> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:39: >>> ../../../../.././mcf5329/lib/include/libcpu/cache.h:30:6: note: previous >>> declaration of '_CPU_cache_invalidate_instruction_range' was here >>> void _CPU_cache_invalidate_instruction_range(const void *i_addr, size_t >>> n_bytes); >>> ^ >>> >>> bfin/bf537Stamp, or1k/or1k_generic, and m68k/mvme136 should >>> be sufficient to reproduce and fix the problem. >>> >>> -- >>> Joel Sherrill, Ph.D. Director of Research & Development >>> joel.sherr...@oarcorp.comOn-Line Applications Research >>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>> Support Available(256) 722-9985 >>> >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 > -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 BLOCKER - Multiple BSPs fail to build - cache changes?
^^ s/already/only Both are working fine with or1k. Let me know which is better. I'd suggest getting rid of the static declaration as sparc (the only other CPU that empty-implements the same function) implements it without "static". On Fri, Apr 24, 2015 at 6:20 PM, Hesham ALMatary wrote: > Gedare, > > The corresponding function declaration and implementation are included > from libcpu/shared. There are two solutions to fix this for the all > broken BSPs: > 1- Get rid of _CPU_cache_invalidate_instruction_range declaration at > libcpu/shared/include/cache.h, since this functions is already called > at cache_manager.c > 2- Get rid of the static keyword at cache_manager.c. > > On Fri, Apr 24, 2015 at 6:13 PM, Joel Sherrill > wrote: >> >> >> On 4/24/2015 12:07 PM, Hesham ALMatary wrote: >>> Hi, >>> >>> I believe this commit is the one which broke it [1], I'm going to >>> discard the usage of the shared cache_manager.c file and provide or1k >>> with private stubs. >>> >>> [1] >>> https://github.com/RTEMS/rtems/commit/26c142e5ad4a63ad42baa17159c1821afe473a00 >> This also broke two other architectures. Fixing it for the or1k is not >> sufficient. >> Please either provide proper caching for the or1k or fix it in a way that >> fixes all three architectures. >>> On Fri, Apr 24, 2015 at 5:16 PM, Joel Sherrill >>> wrote: Hi Multiple BSPs failed to build in my overnight sweep. All bfin and or1k BSPs plus 18 m68k failed with this: ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:340:1: error: static declaration of '_CPU_cache_invalidate_instruction_range' follows non-static declaration _CPU_cache_invalidate_instruction_range( ^ In file included from ../../../../../../../rtems/c/src/lib/libcpu/m68k/shared/cache/cache_.h:37:0, from ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:39: ../../../../.././mcf5329/lib/include/libcpu/cache.h:30:6: note: previous declaration of '_CPU_cache_invalidate_instruction_range' was here void _CPU_cache_invalidate_instruction_range(const void *i_addr, size_t n_bytes); ^ bfin/bf537Stamp, or1k/or1k_generic, and m68k/mvme136 should be sufficient to reproduce and fix the problem. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel >>> >>> >> >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@oarcorp.comOn-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available(256) 722-9985 >> > > > > -- > Hesham -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 BLOCKER - Multiple BSPs fail to build - cache changes?
- Hesham ALMatary schrieb: > Gedare, > > The corresponding function declaration and implementation are included > from libcpu/shared. There are two solutions to fix this for the all > broken BSPs: > 1- Get rid of _CPU_cache_invalidate_instruction_range declaration at > libcpu/shared/include/cache.h, since this functions is already called > at cache_manager.c Yes, this _CPU_cache_invalidate_instruction_range() declaration is a complete nonsense in this file. > 2- Get rid of the static keyword at cache_manager.c. > > On Fri, Apr 24, 2015 at 6:13 PM, Joel Sherrill > wrote: > > > > > > On 4/24/2015 12:07 PM, Hesham ALMatary wrote: > >> Hi, > >> > >> I believe this commit is the one which broke it [1], I'm going to > >> discard the usage of the shared cache_manager.c file and provide or1k > >> with private stubs. > >> > >> [1] > >> https://github.com/RTEMS/rtems/commit/26c142e5ad4a63ad42baa17159c1821afe473a00 > > This also broke two other architectures. Fixing it for the or1k is not > > sufficient. > > Please either provide proper caching for the or1k or fix it in a way that > > fixes all three architectures. > >> On Fri, Apr 24, 2015 at 5:16 PM, Joel Sherrill > >> wrote: > >>> Hi > >>> > >>> Multiple BSPs failed to build in my overnight sweep. All > >>> bfin and or1k BSPs plus 18 m68k failed with this: > >>> > >>> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:340:1: > >>> error: static declaration of '_CPU_cache_invalidate_instruction_range' > >>> follows non-static declaration > >>> _CPU_cache_invalidate_instruction_range( > >>> ^ > >>> In file included from > >>> ../../../../../../../rtems/c/src/lib/libcpu/m68k/shared/cache/cache_.h:37:0, > >>> from > >>> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:39: > >>> ../../../../.././mcf5329/lib/include/libcpu/cache.h:30:6: note: previous > >>> declaration of '_CPU_cache_invalidate_instruction_range' was here > >>> void _CPU_cache_invalidate_instruction_range(const void *i_addr, size_t > >>> n_bytes); > >>> ^ > >>> > >>> bfin/bf537Stamp, or1k/or1k_generic, and m68k/mvme136 should > >>> be sufficient to reproduce and fix the problem. > >>> > >>> -- > >>> Joel Sherrill, Ph.D. Director of Research & Development > >>> joel.sherr...@oarcorp.comOn-Line Applications Research > >>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 > >>> Support Available(256) 722-9985 > >>> > >>> ___ > >>> devel mailing list > >>> devel@rtems.org > >>> http://lists.rtems.org/mailman/listinfo/devel > >> > >> > > > > -- > > Joel Sherrill, Ph.D. Director of Research & Development > > joel.sherr...@oarcorp.comOn-Line Applications Research > > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > > Support Available(256) 722-9985 > > > > > > -- > Hesham > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- 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.huber at 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: 4.11 BLOCKER - Multiple BSPs fail to build - cache changes?
- Hesham ALMatary schrieb: > ^^ > s/already/only > > Both are working fine with or1k. Let me know which is better. I'd > suggest getting rid of the static declaration as sparc (the only other > CPU that empty-implements the same function) implements it without > "static". > Providing an empty implementation is wrong. Thus function needs to get removed for the SPARC. > > On Fri, Apr 24, 2015 at 6:20 PM, Hesham ALMatary > wrote: > > Gedare, > > > > The corresponding function declaration and implementation are included > > from libcpu/shared. There are two solutions to fix this for the all > > broken BSPs: > > 1- Get rid of _CPU_cache_invalidate_instruction_range declaration at > > libcpu/shared/include/cache.h, since this functions is already called > > at cache_manager.c > > 2- Get rid of the static keyword at cache_manager.c. > > > > On Fri, Apr 24, 2015 at 6:13 PM, Joel Sherrill > > wrote: > >> > >> > >> On 4/24/2015 12:07 PM, Hesham ALMatary wrote: > >>> Hi, > >>> > >>> I believe this commit is the one which broke it [1], I'm going to > >>> discard the usage of the shared cache_manager.c file and provide or1k > >>> with private stubs. > >>> > >>> [1] > >>> https://github.com/RTEMS/rtems/commit/26c142e5ad4a63ad42baa17159c1821afe473a00 > >> This also broke two other architectures. Fixing it for the or1k is not > >> sufficient. > >> Please either provide proper caching for the or1k or fix it in a way that > >> fixes all three architectures. > >>> On Fri, Apr 24, 2015 at 5:16 PM, Joel Sherrill > >>> wrote: > Hi > > Multiple BSPs failed to build in my overnight sweep. All > bfin and or1k BSPs plus 18 m68k failed with this: > > ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:340:1: > error: static declaration of '_CPU_cache_invalidate_instruction_range' > follows non-static declaration > _CPU_cache_invalidate_instruction_range( > ^ > In file included from > ../../../../../../../rtems/c/src/lib/libcpu/m68k/shared/cache/cache_.h:37:0, > from > ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:39: > ../../../../.././mcf5329/lib/include/libcpu/cache.h:30:6: note: previous > declaration of '_CPU_cache_invalidate_instruction_range' was here > void _CPU_cache_invalidate_instruction_range(const void *i_addr, size_t > n_bytes); > ^ > > bfin/bf537Stamp, or1k/or1k_generic, and m68k/mvme136 should > be sufficient to reproduce and fix the problem. > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > >>> > >>> > >> > >> -- > >> Joel Sherrill, Ph.D. Director of Research & Development > >> joel.sherr...@oarcorp.comOn-Line Applications Research > >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 > >> Support Available(256) 722-9985 > >> > > > > > > > > -- > > Hesham > > > > -- > Hesham > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- 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.huber at 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: 4.11 BLOCKER - Multiple BSPs fail to build - cache changes?
On Fri, Apr 24, 2015 at 6:38 PM, Sebastian Huber wrote: > > - Hesham ALMatary schrieb: >> ^^ >> s/already/only >> >> Both are working fine with or1k. Let me know which is better. I'd >> suggest getting rid of the static declaration as sparc (the only other >> CPU that empty-implements the same function) implements it without >> "static". >> > > Providing an empty implementation is wrong. Thus function needs to get > removed for the SPARC. > Agreed. If deleted will this break other SPARC BSPs that depend on this empty implementation? I don't know which SPARC BSPs do. >> >> On Fri, Apr 24, 2015 at 6:20 PM, Hesham ALMatary >> wrote: >> > Gedare, >> > >> > The corresponding function declaration and implementation are included >> > from libcpu/shared. There are two solutions to fix this for the all >> > broken BSPs: >> > 1- Get rid of _CPU_cache_invalidate_instruction_range declaration at >> > libcpu/shared/include/cache.h, since this functions is already called >> > at cache_manager.c >> > 2- Get rid of the static keyword at cache_manager.c. >> > >> > On Fri, Apr 24, 2015 at 6:13 PM, Joel Sherrill >> > wrote: >> >> >> >> >> >> On 4/24/2015 12:07 PM, Hesham ALMatary wrote: >> >>> Hi, >> >>> >> >>> I believe this commit is the one which broke it [1], I'm going to >> >>> discard the usage of the shared cache_manager.c file and provide or1k >> >>> with private stubs. >> >>> >> >>> [1] >> >>> https://github.com/RTEMS/rtems/commit/26c142e5ad4a63ad42baa17159c1821afe473a00 >> >> This also broke two other architectures. Fixing it for the or1k is not >> >> sufficient. >> >> Please either provide proper caching for the or1k or fix it in a way that >> >> fixes all three architectures. >> >>> On Fri, Apr 24, 2015 at 5:16 PM, Joel Sherrill >> >>> wrote: >> Hi >> >> Multiple BSPs failed to build in my overnight sweep. All >> bfin and or1k BSPs plus 18 m68k failed with this: >> >> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:340:1: >> error: static declaration of '_CPU_cache_invalidate_instruction_range' >> follows non-static declaration >> _CPU_cache_invalidate_instruction_range( >> ^ >> In file included from >> ../../../../../../../rtems/c/src/lib/libcpu/m68k/shared/cache/cache_.h:37:0, >> from >> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:39: >> ../../../../.././mcf5329/lib/include/libcpu/cache.h:30:6: note: previous >> declaration of '_CPU_cache_invalidate_instruction_range' was here >> void _CPU_cache_invalidate_instruction_range(const void *i_addr, size_t >> n_bytes); >> ^ >> >> bfin/bf537Stamp, or1k/or1k_generic, and m68k/mvme136 should >> be sufficient to reproduce and fix the problem. >> >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@oarcorp.comOn-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available(256) 722-9985 >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> >>> >> >>> >> >> >> >> -- >> >> Joel Sherrill, Ph.D. Director of Research & Development >> >> joel.sherr...@oarcorp.comOn-Line Applications Research >> >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> >> Support Available(256) 722-9985 >> >> >> > >> > >> > >> > -- >> > Hesham >> >> >> >> -- >> Hesham >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > -- > 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.huber at embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Fix broken BSPs due to a shared cache function declaration.
Get rid of _CPU_cache_invalidate_instruction_range declaration as it doesn't make sense here. --- c/src/lib/libcpu/shared/include/cache.h | 1 - 1 file changed, 1 deletion(-) diff --git a/c/src/lib/libcpu/shared/include/cache.h b/c/src/lib/libcpu/shared/include/cache.h index d9df423..2699791 100644 --- a/c/src/lib/libcpu/shared/include/cache.h +++ b/c/src/lib/libcpu/shared/include/cache.h @@ -27,7 +27,6 @@ void _CPU_cache_invalidate_data_range(const void *d_addr, size_t n_bytes); void _CPU_cache_invalidate_1_data_line(const void *d_addr); void _CPU_cache_freeze_data(void); void _CPU_cache_unfreeze_data(void); -void _CPU_cache_invalidate_instruction_range(const void *i_addr, size_t n_bytes); void _CPU_cache_invalidate_1_instruction_line(const void *d_addr); void _CPU_cache_freeze_instruction(void); void _CPU_cache_unfreeze_instruction(void); -- 2.1.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 BLOCKER - Multiple BSPs fail to build - cache changes?
- Hesham ALMatary schrieb: > On Fri, Apr 24, 2015 at 6:38 PM, Sebastian Huber > wrote: > > > > - Hesham ALMatary schrieb: > >> ^^ > >> s/already/only > >> > >> Both are working fine with or1k. Let me know which is better. I'd > >> suggest getting rid of the static declaration as sparc (the only other > >> CPU that empty-implements the same function) implements it without > >> "static". > >> > > > > Providing an empty implementation is wrong. Thus function needs to get > > removed for the SPARC. > > > Agreed. If deleted will this break other SPARC BSPs that depend on > this empty implementation? I don't know which SPARC BSPs do. The only consumer of this function is cache_manager.c. In case the BSP provides this function and it must define CPU_CACHE_SUPPORT_PROVIDES_RANGE_FUNCTIONS and vice versa. It should be also static inline since the reason for its introduction was performance. -- 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.huber at 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: [rtems commit] posix: Use right thread dispatch disable function
- Gedare Bloom schrieb: > Why do we have these two functions with similar names and commented to > have the same functionality? They have different commments, but yes the naming is not that brilliant. > If one is for SMP and the other for UP, > should they be unified or is there a good reason to have separate > functions? One acquires the Giant lock and the other not. In the long run _Thread_Disable_dispatch() and _Thread_Enable_dispatch() will go away (= Giant lock removed). -- 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.huber at 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: [PATCH] Beagle BSP Improvements (GPIO driver)
Hi All, First time emailing this list. I'll chime in as a interested party with development experience. I agree wholeheartedly with Joel. Having a single API for all GPIO access would be great. A few additional things to consider: - Sometimes applications will want 'blindingly fast' access to GPIO. Some abstractions may add too many levels of indirection in order to be generic enough. It might be worthwhile making the generic RTEMS API as generic as possible, but still making an effort to make a consistent low level API that uses trivial inline functions using address and bit manipulation. - Another potential issues is atomic writing of individual bits. A gerneric RTEMS API would be nice. Of course, only some hardware supports atomic bit sets, so unsupported hardware would have to disable interrupts/lock the scheduler (1). There are some good thoughts about this topic here: http://www.ethernut.de/nutwiki/Unified_GPIO_Implementation They raise the point that some architectures have special properties you can set on IO pins, such as pullup strength, drive mode (Open collector, push pull, etc). This could be exposed via a rtems_gpio_board_specific_config(...). I haven't given this as much thought. Isaac On 04/24/2015 01:11 PM, Joel Sherrill wrote: On 4/24/2015 11:48 AM, Ben Gras wrote: All, Big improvement. The video shows that the bit logic for setting & clearing is likely sound - for the first byte at least ;-). Good test. My comments about the code are - gpio_select_pin write a whole 0 byte instead of updating a single bit, as we talked about on IRC - gedare's suggestion to use a single function to update bits in registers is good - you can use this for gpio_select_pin, gpio_set and gpio_clear. - i don't like the addition of arm_delay() in the bsp code. if it's not bsp-specific (and it isn't), it shouldn't be there. - the AM335X-specific code isn't made conditional My comment about the API that is: I don't like it that hardware-specific info (GPIO base registers) is somewhat external to the BSP. To my mind, the application should only deal with bank numbers and pin numbers. So either we need 128 more #defines of the GPIO_PIN struct in the current vein, meaning inline struct initializers are passed around (ew) and we rely on quite a lot of app discipline to keep it clean (ew); or we need an api like gpio_config(&gpio_conf); /* retrieve number of gpio banks & pins per bank, possibly more info */ gpio_select_pin(&gpio_pin, bank_number, pin_number, DIGITAL_OUTPUT); /* fill in gpio_pin struct to use this pin */ gpio_set(&gpio_pin); gpio_clear(&gpio_pin); gpio_release_pin(&gpio_pin); /* allows repurposing this pin */ this way the configuring of gpio_pin (containing hardware-specific info) is more internal to the BSP, and the app would have to actively subvert the api (look in the gpio_pin struct) and is less prone to be written badly by accident (hardcoding hardware addresses in the app). Thoughts anyone? We need a generic rtems_gpio_XXX API set. That was what I took at initial shot at with the multio code. I started mentally with separate APIs completely for analog and discretes but since I was handed a baseboard with 32 bit GPIO pins and an add-on board with ADCs, DACs, and more GPIOs, I needed a unified interface. The collection of various IO types on a board is common. The application should be completely independent of the BSP. My app will have to know that "the red warning light" is bank 1, pin 3 on board X and bank 7, pin 12 when using another board. That is an application issue. The BSP/system configuration has to present a single API to the app. Remember that the system integrator may add boards. So the "system configuration" may include things not on the baseboard. The SIGAda 2009 presentation I sent privately a few days ago had that configuration and was what I did the API work I did for. On Thu, Apr 23, 2015 at 8:35 PM, Ketul Shah wrote: Hi all, Ben Gras thanks for your comments and encouragement for merging with mainline as a motivation for me. I worked and redeveloped code for gpio driver also tried to approach towards common api. I tried to address most of the comments. Herewith I attached my patch. Would be happy to hear comments on that. You can also find out my gist or commit on https://github.com/RTEMS/rtems . I have been updating my work on https://github.com/ketul93/RTEMS-on-BBB. Live demo of the updated code is found on :- https://youtu.be/bXurelOA3i0 Thanks. Regards, ketul On 20 April 2015 at 19:50, Ben Gras wrote: All, Good contribution, thank you. For GSOC, this is good proof of being able to progress and get something real working based on documentation. Great! If you want this merged with mainline - which I fully encourage! - then I suggest the following should be added to/changed first: - make the code that uses AM335X (beaglebone) specific registers, AM335X-specific :) i.e. add #if IS_AM335X around
Re: [PATCH] [RPI BSP] mailbox
On Apr 23, 2015, at 10:20 AM, Alan Cudmore wrote:
Hi Qiao,
Functionally, this code looks good to me. It builds without warnings for the Pi and Pi2, and I was able to make the calls to init the frame buffer on the Pi B+.
When you did the frame buffer test, what was your MMU table entry for the
mailbox/framebuffer?
In fact, I've got questions with the MMU table set up. It seems that the memory
is enabled by page because I've found that I can also access to the address out
of the range that I've set up.
Here is what I've added.
{
.begin = 0xC11F4C8,
.end = 0xC11F4C8 + 0x1000,
.flags = ARMV7_MMU_DATA_READ_WRITE
}
The fb buffer in my case appears to around 0xC11F4C8, and the size is not the
actual size. But it works. I know it's not proper, I just use this for tests.
If we've enabled l2 cache, the memory mapping would be 0x4000, while the
mapping would be 0xC000 instead if l2 cache disabled. Normally it can be
configured in the config.txt file. What do you think is a better way to find it
out whether l2 cache is enabled in order to use the proper mapping?
I've read through the video core processor's available properties settings.
Here's what we can use for framebuffer:
allocate/release buffer
set blank screen
get/set/test display size
get/set/test buffer size
get/set/test depth
get/set/test pixel order
get/set/test alpha mode
get pitch
get/set/test virtual offset
get/set/test overscan
get/set/test palette
set cursor info
set cursor state
As I've already got a fb_init which works and we can get the pointer with
ioctrl correctly and draw something, what else should be implemented for fb?
The other bsps' palettes are hard coded, I wonder if I should also setup the
palette and allow users to adjust it by ioctrl. What about other properties?
I'm not sure where to go from here.
I tried to compile gtk for it. The libpng etc can be installed and I'm working
on some samples to test them. Only the nxlib failed because we haven't yet the
keyboard support (mouse support can be switch off, but I can't find out how to
build the lib without keyboard).
Thanks,
Alan
On Apr 19, 2015, at 3:17 PM, QIAO YANG wrote:
Here is a modified patch for mailbox. If there's still anything against the
convention, please point it out and I'll correct it immediately. The mailbox
implementation might also be needed by other rpi bsp developpers.
--
diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index c6133df..70bc01d 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -43,6 +43,7 @@ include_bsp_HEADERS += ../shared/include/arm-release-id.h
include_bsp_HEADERS += include/irq.h
include_bsp_HEADERS += include/mmu.h
include_bsp_HEADERS += include/usart.h
+include_bsp_HEADERS += include/mailbox.h
include_bsp_HEADERS += include/raspberrypi.h
include_libcpu_HEADERS = ../../../libcpu/arm/shared/include/cache_.h \
@@ -123,6 +124,9 @@ libbsp_a_SOURCES += misc/timer.c
# I2C
+# Mailbox
+libbsp_a_SOURCES += misc/mailbox.c
+
# Cache
libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c
libbsp_a_SOURCES += ../../../libcpu/arm/shared/include/cache_.h
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
new file mode 100644
index 000..fa6a0c2
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
@@ -0,0 +1,33 @@
+/**
+ * @file
+ *
+ * @ingroup raspberrypi
+ *
+ * @brief mailbox support.
+ */
+
+/*
+ * Copyright (c) 2015 Yang Qiao
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ *
+ * http://www.rtems.org/license/LICENSE
+ *
+ */
+
+#ifndef LIBBSP_ARM_RASPBERRYPI_MAILBOX_H
+#define LIBBSP_ARM_RASPBERRYPI_MAILBOX_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+extern unsigned int raspberrypi_mailbox_read(unsigned int channel);
+extern void raspberrypi_mailbox_write(unsigned int channel, unsigned int data);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* LIBBSP_ARM_RASPBERRYPI_MAILBOX_H */
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
index c33e22a..3240404 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
@@ -208,6 +208,55 @@
/** @} */
+ /**
+ * @name Mailbox Registers
+ *
+ * @{
+ */
+
+#define BCM2835_MBOX_BASE (RPI_PERIPHERAL_BASE+0xB880)
+
+#define BCM2835_MBOX_PEEK (BCM2835_MBOX_BASE+0x10)
+#define BCM2835_MBOX_READ (BCM2835_MBOX_BASE+0x00)
+#define BCM2835_MBOX_WRITE (BCM2835_MBOX_BASE+0x20)
+#define BCM2835_MBOX_STATUS (BCM2835_MBOX_BASE+0x18)
+#define BCM2835_MBOX_SENDER (BCM2835_MBOX_BASE+0x14)
+#define BCM2835_MBOX_CONFIG (BCM2835_MBOX_BASE+0x1C)
+
+#define BCM2835_MBOX_
Re: [PATCH] [RPI BSP] mailbox
On Apr 23, 2015, at 10:27 AM, Joel Sherrill wrote:
On 4/19/2015 2:17 PM, QIAO YANG wrote:
Here is a modified patch for mailbox. If there's still anything against the
convention, please point it out and I'll correct it immediately. The mailbox
implementation might also be needed by other rpi bsp developpers.
My understanding is that the mailbox is used to determine the board
version and memory size.
What did you use the mailbox for to test it?
The mailbox is the main way to communicate with videocore processor, not only
to get board informations and cpu state. I use this to get the framebuffer
pointer and its related properties.
--
diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index c6133df..70bc01d 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -43,6 +43,7 @@ include_bsp_HEADERS += ../shared/include/arm-release-id.h
include_bsp_HEADERS += include/irq.h
include_bsp_HEADERS += include/mmu.h
include_bsp_HEADERS += include/usart.h
+include_bsp_HEADERS += include/mailbox.h
include_bsp_HEADERS += include/raspberrypi.h
include_libcpu_HEADERS = ../../../libcpu/arm/shared/include/cache_.h \
@@ -123,6 +124,9 @@ libbsp_a_SOURCES += misc/timer.c
# I2C
+# Mailbox
+libbsp_a_SOURCES += misc/mailbox.c
+
# Cache
libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c
libbsp_a_SOURCES += ../../../libcpu/arm/shared/include/cache_.h
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
new file mode 100644
index 000..fa6a0c2
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
@@ -0,0 +1,33 @@
+/**
+ * @file
+ *
+ * @ingroup raspberrypi
+ *
+ * @brief mailbox support.
+ */
+
+/*
+ * Copyright (c) 2015 Yang Qiao
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ *
+ * http://www.rtems.org/license/LICENSE
+ *
+ */
+
+#ifndef LIBBSP_ARM_RASPBERRYPI_MAILBOX_H
+#define LIBBSP_ARM_RASPBERRYPI_MAILBOX_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+extern unsigned int raspberrypi_mailbox_read(unsigned int channel);
+extern void raspberrypi_mailbox_write(unsigned int channel, unsigned int data);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* LIBBSP_ARM_RASPBERRYPI_MAILBOX_H */
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
index c33e22a..3240404 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
@@ -208,6 +208,55 @@
/** @} */
+ /**
+ * @name Mailbox Registers
+ *
+ * @{
+ */
+
+#define BCM2835_MBOX_BASE (RPI_PERIPHERAL_BASE+0xB880)
+
+#define BCM2835_MBOX_PEEK (BCM2835_MBOX_BASE+0x10)
+#define BCM2835_MBOX_READ (BCM2835_MBOX_BASE+0x00)
+#define BCM2835_MBOX_WRITE (BCM2835_MBOX_BASE+0x20)
+#define BCM2835_MBOX_STATUS (BCM2835_MBOX_BASE+0x18)
+#define BCM2835_MBOX_SENDER (BCM2835_MBOX_BASE+0x14)
+#define BCM2835_MBOX_CONFIG (BCM2835_MBOX_BASE+0x1C)
+
+#define BCM2835_MBOX_SUCCESS (BCM2835_MBOX_BASE+0x8000)
+#define BCM2835_MBOX_FULL (BCM2835_MBOX_BASE+0x8000)
+#define BCM2835_MBOX_EMPTY (BCM2835_MBOX_BASE+0x4000)
+
+/**
+* @name Mailbox Channels
+*
+* @{
+*/
+
+/* Power Manager channel */
+#define BCM2835_MBOX_CHANNEL_PM 0
+/* Framebuffer channel */
+#define BCM2835_MBOX_CHANNEL_FB 1
+ /* Virtual UART channel */
+#define BCM2835_MBOX_CHANNEL_VUART 2
+ /* VCHIQ channel */
+#define BCM2835_MBOX_CHANNEL_VCHIQ 3
+ /* LEDs channel */
+#define BCM2835_MBOX_CHANNEL_LED4
+ /* Button channel */
+#define BCM2835_MBOX_CHANNEL_BUTTON 5
+ /* Touch screen channel */
+#define BCM2835_MBOX_CHANNEL_TOUCHS 6
+/* Property tags (ARM <-> VC) channel */
+#define BCM2835_MBOX_CHANNEL_PROP_AVC 8
+ /* Property tags (VC <-> ARM) channel */
+#define BCM2835_MBOX_CHANNEL_PROP_VCA 9
+
+/** @} */
+
+
+/** @} */
+
/** @} */
diff --git a/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c
new file mode 100644
index 000..2a63a41
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c
@@ -0,0 +1,44 @@
+/**
+ * @file
+ *
+ * @ingroup raspberrypi
+ *
+ * @brief mailbox support.
+ */
+
+/*
+ * Copyright (c) 2015 Yang Qiao
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ *
+ * http://www.rtems.org/license/LICENSE
+ *
+ */
+
+#include
+#include
+#include
+
+unsigned int raspberrypi_mailbox_read (unsigned int channel)
+{
+ unsigned int data;
+ unsigned int read_channel;
+
+ while ( 1 )
+ {
+while (BCM2835_REG (BCM2835_MBOX_STATUS ) & BCM2835_MBOX_EMPTY);
+data = BCM2835_REG (BCM2835_MBOX_READ );
+read_channel =
