On May 12, 2015, at 2:11 AM, Ian Campbell wrote:
> On Tue, 2015-05-12 at 01:33 -0700, Rick Thomas wrote:
>> On May 6, 2015, at 3:35 AM, Rick Thomas wrote:
>>
>>>
>>> On May 6, 2015, at 3:27 AM, Ian Campbell wrote:
>>>
It would be preferable to test the thing in Sid before the upload to
On Tue, 2015-05-12 at 01:33 -0700, Rick Thomas wrote:
> On May 6, 2015, at 3:35 AM, Rick Thomas wrote:
>
> >
> > On May 6, 2015, at 3:27 AM, Ian Campbell wrote:
> >
> >> It would be preferable to test the thing in Sid before the upload to
> >> jessie-proposed-updates
> >
> > I’ll keep an eye
On May 6, 2015, at 3:35 AM, Rick Thomas wrote:
>
> On May 6, 2015, at 3:27 AM, Ian Campbell wrote:
>
>> It would be preferable to test the thing in Sid before the upload to
>> jessie-proposed-updates
>
> I’ll keep an eye out for it.
>
> But I don’t have one of the cubox models without the b
On May 6, 2015, at 3:27 AM, Ian Campbell wrote:
> It would be preferable to test the thing in Sid before the upload to
> jessie-proposed-updates
I’ll keep an eye out for it.
But I don’t have one of the cubox models without the battery-backed RTC, so I
won’t be able to test that case. Is the
Control: submitter -1 Rick Thomas
On Wed, 2015-05-06 at 03:00 -0700, Rick Thomas wrote:
> OK, How will I identify the upload when I see it? The box is running
> Debian/Sid and I do regular updates. So presumably, I’ll see a
> “linux-image-3.16.0-4-armmp” package go by sometime soon?
I think th
Processing control commands:
> submitter -1 Rick Thomas
Bug #782364 [src:linux] linux-image-3.16.0-4-armmp: please configure drivers
for both Cubox i4pro real time clocks
Changed Bug submitter to 'Rick Thomas ' from 'Rick Thomas
'
--
782364: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=78
OK, How will I identify the upload when I see it? The box is running
Debian/Sid and I do regular updates. So presumably, I’ll see a
“linux-image-3.16.0-4-armmp” package go by sometime soon? And I’ll know I’ve
got it when I see two /dev/rtc* devices?
As for “rbtho...@cube.rcthomas.org” — I’m
On Sat, 2015-05-02 at 17:21 +0100, Ian Campbell wrote:
> We typically build RTCs statically (for this sort of reason) so it seems
> like the right thing for us to do here is to build both in.
Which I've now done in SVN. Rick, please test the next upload.
Also, Rick, I'm getting messages from my M
On Sat, 2015-05-02 at 17:12 +0100, Russell King - ARM Linux wrote:
> On Sat, May 02, 2015 at 05:01:04PM +0100, Ian Campbell wrote:
> > So is your advice for a multi platform kernel supporting all Cubox
> > devices to just enable both and to sort out any syncing/naming etc in
> > userspace?
>
> I d
On Sat, May 02, 2015 at 05:01:04PM +0100, Ian Campbell wrote:
> On Wed, 2015-04-29 at 09:57 +0100, Russell King - ARM Linux wrote:
> > On Sat, Apr 11, 2015 at 01:08:50AM +0100, Ben Hutchings wrote:
> > > If this RTC is not battery backed, it seems like it ought to be disabled
> > > in this board's
On Wed, 2015-04-29 at 09:57 +0100, Russell King - ARM Linux wrote:
> On Sat, Apr 11, 2015 at 01:08:50AM +0100, Ben Hutchings wrote:
> > If this RTC is not battery backed, it seems like it ought to be disabled
> > in this board's device tree.
>
> It's not that simple.
>
> On the lower-end models,
On Sat, Apr 11, 2015 at 01:08:50AM +0100, Ben Hutchings wrote:
> If this RTC is not battery backed, it seems like it ought to be disabled
> in this board's device tree.
It's not that simple.
On the lower-end models, the on-SoC RTC is the only RTC there is. If
it were disabled, there would be no
On Apr 28, 2015, at 8:02 PM, Fabio Estevam wrote:
> On Fri, Apr 10, 2015 at 9:08 PM, Ben Hutchings wrote:
>
>>> Whenever I reset my cubox-i4Pro by disconnecting the power plug, the
>>> hardware real-time-clock gets
>>> reset to midnight UTC, Dec 31, 1970.
>>> Even though the SolidRun literatu
On Apr 28, 2015, at 8:02 PM, Fabio Estevam wrote:
> On Fri, Apr 10, 2015 at 9:08 PM, Ben Hutchings wrote:
>
>>> Whenever I reset my cubox-i4Pro by disconnecting the power plug, the
>>> hardware real-time-clock gets
>>> reset to midnight UTC, Dec 31, 1970.
>>> Even though the SolidRun literatu
On Fri, Apr 10, 2015 at 9:08 PM, Ben Hutchings wrote:
>> Whenever I reset my cubox-i4Pro by disconnecting the power plug, the
>> hardware real-time-clock gets
>> reset to midnight UTC, Dec 31, 1970.
>> Even though the SolidRun literature says that the i4Pro has a battery backed
>> RTC.
> If th
Processing control commands:
> severity -1 important
Bug #782364 [src:linux] linux-image-3.16.0-4-armmp: please configure drivers
for both Cubox i4pro real time clocks
Severity set to 'important' from 'wishlist'
--
782364: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782364
Debian Bug Track
Control: severity -1 important
On Fri, 2015-04-10 at 16:28 -0700, Rick Thomas wrote:
> Package: src:linux
> Version: 3.16.7-ckt7-1
> Severity: wishlist
> Tags: newcomer
>
> Whenever I reset my cubox-i4Pro by disconnecting the power plug, the hardware
> real-time-clock gets
> reset to midnight UT
Package: src:linux
Version: 3.16.7-ckt7-1
Severity: wishlist
Tags: newcomer
Whenever I reset my cubox-i4Pro by disconnecting the power plug, the hardware
real-time-clock gets
reset to midnight UTC, Dec 31, 1970.
Even though the SolidRun literature says that the i4Pro has a battery backed
RTC.
A
18 matches
Mail list logo
