Re: GSOC student question

Dear all, On 05/22/2017 11:56 AM, Joel Sherrill wrote: > > > On Mon, May 22, 2017 at 10:11 AM, Gedare Bloom > wrote: > > I think the i2c was developed and tested only on the BeagleBone Black. > I don't think anyone has used the xm yet, though

Re: [PATCH] modify punitvara's works on BBB i2c, and now can read the eeprom info.

Dear all, SZ, great initiative. Gedare and Sebastian have commented. For my part, can I just check - the implementation is supposed to be generic to i2c devices, correct? If so, can you explain what read_eeprom is for? Is it just as demo? Is the code generic otherwise? Cheers, Ben On

Re: Building toolset for Beaglebone with RSB fails (for me).

All, I see, yes. Noted. I will try to find time for this soon but it may be a little while. Ben On 02/10/2017 03:24 PM, Joel Sherrill wrote: > GCC does not keep snapshots forever. Ben's instructions and git repo > must be behind the master at git.rtems.org . > clone the

Re: [PATCH v3 2/2] Subject: Update PWM driver imported from BBBIO

All, On Fri, Jul 1, 2016 at 11:12 PM, Martin Galvan wrote: > Hi Punit, thanks for the patch. As we spoke in the group chat with the other > mentors, this seems to > be good for a first version. I'll be pointing out the required changes for > the next

Re: [PATCH] Beaglebone: Fix the IRQ handling code

16 at 11:09 AM, Martin Galvan > <martin.gal...@tallertechnologies.com> wrote: >> Thanks Ben! Indeed, any further testing is more than welcome :) >> >> On Thu, Feb 11, 2016 at 7:55 PM, Ben Gras <b...@shrike-systems.com> wrote: >>> This looks like great work

Re: [PATCH] Beaglebone: Fix the IRQ handling code

This looks like great work. Please let me test it (I'll try the GPIO interrupt trigger) & I'll merge it as soon as I have time. Thank you! Cheers, Ben On Thu, Feb 11, 2016 at 3:27 PM, Martin Galvan wrote: > This patch makes the following changes to the

[PATCH] fail gracefully when pax is not found

https://devel.rtems.org/ticket/2437 Attachment to that ticket is a clean fix for: If pax is not found by configure, the empty PAX variable is used in e.g. this line: $(PAX) -w -f $@ $< Causing the 'w' command to be invoked: 21:37:25 up 6 min, 3 users, load average: 1,90, 1,14, 0,49 USER TTY

BBB GPIO status

All, I built tested pushed Ketul's GPIO BBB implementation, it's working nicely with the generic GPIO layer. Remaining to get working: - IRQ-triggering in digital in - pullup configuration Well done Ketul! ___ devel mailing list devel@rtems.org

Re: [PATCH] Temporary fix for ethernet rx intr hang issue and Disable cache

All, I really don't want to merge a line like: +if ( ! ( irq == 40 || irq == 41 || irq == 42 || irq == 43 ) ) in the generic interrupt dispatch function. At minimum, replace the IRQ numbers with descriptive macro names and comment on why it's needed and that it's temporary. On Sun, Jun

Re: RTC patch for BBB

This changed is now merged. Congratulations thank you Ragunath! On Sun, May 3, 2015 at 1:02 PM, ragu nath ragunath3...@gmail.com wrote: Hi All, I have attached the RTC patch for BBB. I have addressed the comments given for my earlier submission. I am having problems with sending patch

Re: RTC patch for BBB

All, I am happy to merge this. On May 3, 2015 1:02 PM, ragu nath ragunath3...@gmail.com wrote: Hi All, I have attached the RTC patch for BBB. I have addressed the comments given for my earlier submission. I am having problems with sending patch using git send-email. I understand this is

Re: [PATCH] Beagle BSP Improvements (GPIO driver)

the whole thing. On Fri, Apr 24, 2015 at 7:11 PM, Joel Sherrill joel.sherr...@oarcorp.com 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

Re: [PATCH] Beagle BSP Improvements (GPIO driver)

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 ketulshah1...@gmail.com wrote: Hi all, Ben Gras thanks for your comments

Re: [PATCH] Beagle BSP Improvements (GPIO driver)

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

Re: Beagle bsp improvements RTC driver for beaglebone black

All, I built tested the change based on current master. Looks great, ragunath! I agree it's worth addressing Joel's comments. I have two more: - please check in the device read/write functions that you're getting the 'minor' argument that you expect (0), and not return valid data otherwise. -

Re: [PATCH] autoconf changes

Ok reverted. Sorry for the noise everyone. On Sat, Mar 14, 2015 at 10:05 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 3/14/2015 3:44 PM, Ben Gras wrote: I accidentally also merged this commti when I meant to just merge the beagle one.e Should I revert it or is this ok to leave

Re: I was confused

All, About qemu starting x86 executables: as Gedare said you will need some sort of loader to load the ELF into memory (load segments to the right place jump into it at the right place). Interestingly, qemu has a multiboot-compatible (see e.g.

Re: I was confused

BTW merry xmas everyone :-) On Thu, Dec 25, 2014 at 9:59 AM, Ben Gras b...@shrike-systems.com wrote: All, About qemu starting x86 executables: as Gedare said you will need some sort of loader to load the ELF into memory (load segments to the right place jump into it at the right place

[PATCH] fix warnings found when building beagle bsp

The extra includes in console_*.c are to solve a 'no previous prototype' warning. Solves #2212 in trac. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] fix warnings found when building beagle bsp

Okay. On Mon, Dec 15, 2014 at 6:39 PM, Gedare Bloom ged...@gwu.edu wrote: In the future try to use git-send-email if you can. Inline patches especially this small are much easier to review. Go ahead and apply. -Gedare On Mon, Dec 15, 2014 at 11:34 AM, Ben Gras b...@shrike-systems.com

[PATCH] beagle bsp - disable watchdog

From: Ben Gras b...@rtems.org Date: Thu, 4 Dec 2014 18:21:11 +0100 Subject: [PATCH] beagle bsp: disable watchdog on am335x On recent u-boots, the watchdog is turned on / left enabled. The Beaglebone Black rev. C ships with such a u-boot internally so any application booting from it must disable

[PATCH] fix for default configuration for pc386 bsp

All, If USE_VBE_RM is not on, vesa_realmode_bootup_init shouldn't be referenced, but it's always defined, so the test shoudl be #if instead of #ifdef. From 97c14a7558671826bf21f323f7ee593f3e311e15 Mon Sep 17 00:00:00 2001 From: Ben Gras b...@shrike-systems.com Date: Tue, 2 Dec 2014 23:36:59 +0100

Re: [PATCH] more data structures public in mongoose.h

nick.with...@anu.edu.au wrote: On Wed, 2014-11-19 at 19:16 +0100, Ben Gras wrote: The attached patch is a proposed solution to a problem I am having with interfacing with the mongoose httpd for which I've found no canonical (or any other) clean solution. The problem is that some of the data

[PATCH] more data structures public in mongoose.h

it's clear where the divergence is. From 60e135fcc6ae74aa334211046b8f8cc6dd413041 Mon Sep 17 00:00:00 2001 From: Ben Gras b...@shrike-systems.com Date: Tue, 18 Nov 2014 17:29:36 +0100 Subject: [PATCH] mongoose.h --- cpukit/mghttpd/mongoose.c | 21 +++ cpukit/mghttpd/mongoose.h | 67

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

I just checked, it runs on the bbxm hardware too, not just the emulator. On Mon, Nov 3, 2014 at 1:20 PM, Ben Gras b...@shrike-systems.com wrote: All, Ok, as promised, I rebased and re-tested and have found included a portable way of making the SD card image (included in sdcard.sh

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

All, Joel merged these and I updated my blog post to reflect the mainline repo. Thanks Joel! On Mon, Nov 3, 2014 at 8:40 PM, Ben Gras b...@shrike-systems.com wrote: All, I have new patches with some last-minute smoothings added; removed obsolete beagle.cfg, TODO, and separated the more

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

: On 11/3/2014 3:06 PM, Ben Gras wrote: All, Joel merged these and I updated my blog post to reflect the mainline repo. Thanks Joel! Thank you Ben for the nice submission!!! Now to make sure it is reproducible from here and we have merged all the bits into the tools, etc. On Mon

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

Good idea, I did it. On Mon, Nov 3, 2014 at 10:32 PM, Gedare Bloom ged...@rtems.org wrote: Please send a note to rtems-users, some may be interested to hear this addition. -Gedare On Mon, Nov 3, 2014 at 4:28 PM, Ben Gras b...@shrike-systems.com wrote: Indeed. I did right away verify I can

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

of my comments can be done as a follow-on commit. -Gedare On Thu, Jul 24, 2014 at 4:28 PM, Ben Gras b...@shrike-systems.com wrote: Thanks for the fast detailed review. Let me get back to it/you. In the meantime, any other feedback? From anyone I mean. On Thu, Jul 24, 2014 at 4:45 PM

Re: We should release 4.11

All, I'd love the Beagle BSP. I am fighting to find time to polish it, re-test it, and re-submit the patches. To decide whether that's feasible, is freezing the code for the release 'any day now' or more like 'any week now'? On Tue, Aug 19, 2014 at 11:43 PM, Joel Sherrill

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

for generated files. -Gedare On Wed, Jul 23, 2014 at 9:00 PM, Ben Gras b...@shrike-systems.com wrote: All, Full details on how to reproduce all the work from source repositories to scripts utilities to write a complete sd card booting RTEMS and test the whole thing: http

Re: Beagle bsp submit question

Ok great. Yes it was gsoc and the commit mentions it. On Jul 14, 2014 8:10 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On Jul 14, 2014 12:27 PM, Ben Gras b...@shrike-systems.com wrote: Dear all, I'm pretty close to be able to submit an initial version of the Beagle* bsp. I'm

[PATCH] uart-output-char.h: extra offset definition.

All, This patch is submitted as its values are used in my to-be-submitted beagle bsp. --- c/src/lib/libbsp/shared/include/uart-output-char.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/c/src/lib/libbsp/shared/include/uart-output-char.h

Re: BSP question: nested interrupts?

with it, the source pretty much compiles fine in the RTEMS environment. Chris. On 28/04/2014 4:32 AM, Ben Gras wrote: Dear all, I have a question about managing interrupts in a BSP that I have not been able to answer satisfactorily by looking at other BSP code, nor looking throught

Re: BSP question: nested interrupts?

Ok, so the same interrupt will never nest itself then? Good, thanks! On Mon, Apr 28, 2014 at 2:14 PM, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 2014-04-28 13:32, Ben Gras wrote: Dear all, I have a question about managing interrupts in a BSP that I have not been able

Re: [GSOC] RPi BSP RTEMS

All, FWIW to anyone interested in working on the RPi BSP, I noticed the logic in irq.c is suspect; these tests: if (BCM2835_REG(BCM2835_IRQ_BASIC) 0x1) .. else if ( BCM2835_REG(BCM2835_IRQ_BASIC) BCM2835_BIT(19)) presumably intended to use bitwise ANDs. Assuming the current RPi BSP is