Quick question?

Quick question?

[jchludzinski]

I'm trying to bring up an RTOS (vxworks) using u-boot and have had some 
"partial" success:

If I use the 2014 u-boot that comes with Quartus 18.1 (a tarball in the 
download), vxworks successfully boots.

If I clone the github repo 
(https://github.com/altera-opensource/u-boot-socfpga.git)  and build 
u-boot from that (2020), vxworks fails to boot. What appears to be 
happening is an (fpga?) watchdog timer goes off and a HW reset is 
called. Then of course, u-boot reboots.

Any thoughts? Why would this occur with the newer u-boot and not with 
the older u-boot?

---John

Quick question?

[jchludzinski]

On 2020-09-24 17:36, jchludzinski wrote:
> I'm trying to bring up an RTOS (vxworks) using u-boot and have had
> some "partial" success:
> 
> If I use the 2014 u-boot that comes with Quartus 18.1 (a tarball in
> the download), vxworks successfully boots.
> 
> If I clone the github repo
> (https://github.com/altera-opensource/u-boot-socfpga.git)  and build
> u-boot from that (2020), vxworks fails to boot. What appears to be
> happening is an (fpga?) watchdog timer goes off and a HW reset is
> called. Then of course, u-boot reboots.
> 
> Any thoughts? Why would this occur with the newer u-boot and not with
> the older u-boot?
> 
> ---John

I don't see the "Watchdog enabled" message in the output from the older 
u-boot.

Quick question?

[Rayagonda Kokatanur]

On Fri, Sep 25, 2020, 4:32 PM jchludzinski <jchludzinski@vivaldi.net> wrote:

> On 2020-09-24 17:36, jchludzinski wrote:
> > I'm trying to bring up an RTOS (vxworks) using u-boot and have had
> > some "partial" success:
> >
> > If I use the 2014 u-boot that comes with Quartus 18.1 (a tarball in
> > the download), vxworks successfully boots.
> >
> > If I clone the github repo
> > (https://github.com/altera-opensource/u-boot-socfpga.git)  and build
> > u-boot from that (2020), vxworks fails to boot. What appears to be
> > happening is an (fpga?) watchdog timer goes off and a HW reset is
> > called. Then of course, u-boot reboots.
> >
> > Any thoughts? Why would this occur with the newer u-boot and not with
> > the older u-boot?
> >
> > ---John
>
> I don't see the "Watchdog enabled" message in the output from the older
> u-boot.
>

watchdog service starts by default in latest uboot and it's set to 60s.

If you wait for more than 60s at uboot prompt or you os loading takes long
time then watchdog resets.

Define CONFIG_WATCHDOG , this will takes care of resting watchdog.

Thanks,
Rayagonda

>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4187 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200925/6187d11c/attachment.bin>

Quick question?

[jchludzinski]

On 2020-09-25 07:13, Rayagonda Kokatanur wrote:
> On Fri, Sep 25, 2020, 4:32 PM jchludzinski <jchludzinski@vivaldi.net>
> wrote:
> 
>> On 2020-09-24 17:36, jchludzinski wrote:
>>> I'm trying to bring up an RTOS (vxworks) using u-boot and have had
>>> some "partial" success:
>>> 
>>> If I use the 2014 u-boot that comes with Quartus 18.1 (a tarball
>> in
>>> the download), vxworks successfully boots.
>>> 
>>> If I clone the github repo
>>> (https://github.com/altera-opensource/u-boot-socfpga.git)  and
>> build
>>> u-boot from that (2020), vxworks fails to boot. What appears to be
>>> happening is an (fpga?) watchdog timer goes off and a HW reset is
>>> called. Then of course, u-boot reboots.
>>> 
>>> Any thoughts? Why would this occur with the newer u-boot and not
>> with
>>> the older u-boot?
>>> 
>>> ---John
>> 
>> I don't see the "Watchdog enabled" message in the output from the
>> older
>> u-boot.
> 
> watchdog service starts by default in latest uboot and it's set to
> 60s.
> 
> If you wait for more than 60s at uboot prompt or you os loading takes
> long time then watchdog resets.
> 
> Define CONFIG_WATCHDOG , this will takes care of resting watchdog.
> 
> Thanks,
> Rayagonda
> 
>> 
Thanks for the suggestion but this reset occurs while vxworks is in the 
process of booting up.

Could u-boot set a HW watchdog timer before handing control over to 
vxworks and, while vxworks is booting, the timer goes off and calls 
reset?

Quick question?

[Rayagonda Kokatanur]

On Fri, Sep 25, 2020 at 9:29 PM jchludzinski <jchludzinski@vivaldi.net>
wrote:

> On 2020-09-25 07:13, Rayagonda Kokatanur wrote:
> > On Fri, Sep 25, 2020, 4:32 PM jchludzinski <jchludzinski@vivaldi.net>
> > wrote:
> >
> >> On 2020-09-24 17:36, jchludzinski wrote:
> >>> I'm trying to bring up an RTOS (vxworks) using u-boot and have had
> >>> some "partial" success:
> >>>
> >>> If I use the 2014 u-boot that comes with Quartus 18.1 (a tarball
> >> in
> >>> the download), vxworks successfully boots.
> >>>
> >>> If I clone the github repo
> >>> (https://github.com/altera-opensource/u-boot-socfpga.git)  and
> >> build
> >>> u-boot from that (2020), vxworks fails to boot. What appears to be
> >>> happening is an (fpga?) watchdog timer goes off and a HW reset is
> >>> called. Then of course, u-boot reboots.
> >>>
> >>> Any thoughts? Why would this occur with the newer u-boot and not
> >> with
> >>> the older u-boot?
> >>>
> >>> ---John
> >>
> >> I don't see the "Watchdog enabled" message in the output from the
> >> older
> >> u-boot.
> >
> > watchdog service starts by default in latest uboot and it's set to
> > 60s.
> >
> > If you wait for more than 60s at uboot prompt or you os loading takes
> > long time then watchdog resets.
> >
> > Define CONFIG_WATCHDOG , this will takes care of resting watchdog.
> >
> > Thanks,
> > Rayagonda
> >
> >>
> Thanks for the suggestion but this reset occurs while vxworks is in the
> process of booting up.
>
> Could u-boot set a HW watchdog timer before handing control over to
> vxworks and, while vxworks is booting, the timer goes off and calls
> reset?
>

If wdt is not initialized by vxworks then I think uboot wdt will be running
and it will reset.
Did you try  defining  CONFIG_WATCHDOG  in uboot ?


Best regards,
Rayagonda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4187 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200925/2ab79835/attachment.bin>

Quick question?

[jchludzinski]

On 2020-09-25 12:17, Rayagonda Kokatanur wrote:
> On Fri, Sep 25, 2020 at 9:29 PM jchludzinski
> <jchludzinski@vivaldi.net> wrote:
> 
>> On 2020-09-25 07:13, Rayagonda Kokatanur wrote:
>>> On Fri, Sep 25, 2020, 4:32 PM jchludzinski
>> <jchludzinski@vivaldi.net>
>>> wrote:
>>> 
>>>> On 2020-09-24 17:36, jchludzinski wrote:
>>>>> I'm trying to bring up an RTOS (vxworks) using u-boot and have
>> had
>>>>> some "partial" success:
>>>>> 
>>>>> If I use the 2014 u-boot that comes with Quartus 18.1 (a tarball
>>>> in
>>>>> the download), vxworks successfully boots.
>>>>> 
>>>>> If I clone the github repo
>>>>> (https://github.com/altera-opensource/u-boot-socfpga.git)  and
>>>> build
>>>>> u-boot from that (2020), vxworks fails to boot. What appears to
>> be
>>>>> happening is an (fpga?) watchdog timer goes off and a HW reset
>> is
>>>>> called. Then of course, u-boot reboots.
>>>>> 
>>>>> Any thoughts? Why would this occur with the newer u-boot and not
>>>> with
>>>>> the older u-boot?
>>>>> 
>>>>> ---John
>>>> 
>>>> I don't see the "Watchdog enabled" message in the output from the
>>>> older
>>>> u-boot.
>>> 
>>> watchdog service starts by default in latest uboot and it's set to
>>> 60s.
>>> 
>>> If you wait for more than 60s at uboot prompt or you os loading
>> takes
>>> long time then watchdog resets.
>>> 
>>> Define CONFIG_WATCHDOG , this will takes care of resting watchdog.
>>> 
>>> Thanks,
>>> Rayagonda
>>> 
>>>> 
>> Thanks for the suggestion but this reset occurs while vxworks is in
>> the
>> process of booting up.
>> 
>> Could u-boot set a HW watchdog timer before handing control over to
>> vxworks and, while vxworks is booting, the timer goes off and calls
>> reset?
> 
> If wdt is not initialized by vxworks then I think uboot wdt will be
> running and it will reset.
> Did you try  defining  CONFIG_WATCHDOG  in uboot ?
> 
> Best regards,
> Rayagonda

Yes I did. It continues to reset.

---John

Re: Quick question?

[Colin Watson]

On Tue, Dec 10, 2013 at 12:40:28PM +0000, Stojsavljevic, Zoran wrote:
> Version #5536. 

There isn't a direct equivalent of "bzr revno" in git (for what I've
always felt are spurious reasons, but anyway).  "git describe --tags
HEAD", or just the SHA-1 of the tip commit, are generally reasonable
approaches depending on what you're trying to do.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

RE: Quick question?

[Stojsavljevic, Zoran]

Version #5536. 

Thank you,
Zoran
_______
Most of The Time you should be "intel inside" to be capable to think "out of the box".

-----Original Message-----
From: Andrey Borzenkov [mailto:arvidjaar@gmail.com] 
Sent: Monday, December 09, 2013 5:11 PM
To: The development of GNU GRUB
Cc: Stojsavljevic, Zoran
Subject: Re: Quick question?

В Mon, 9 Dec 2013 15:59:19 +0000
"Stojsavljevic, Zoran" <zoran.stojsavljevic@intel.com> пишет:

> Hello,
> 
> I see that grub-devel changed from bzr to git.
> 
> What will be the equivalent of: http://bzr.savannah.gnu.org/lh/grub/trunk/grub/changes ? This link does not work anymore.
> 

I think http://git.savannah.gnu.org/cgit/grub.git/log/ comes close.

> How to find what is the GRUB version, from the current snapshot taken from git (git clone git://git.savannah.gnu.org/grub.git)?
> 

Could you really do it from bzr checkout? Usually it is "git describe HEAD" as long as project maintains release tags.

> Thank you,
> Zoran
> _______
> Most of The Time you should be "intel inside" to be capable to think "out of the box".
> 
> Intel GmbH
> Dornacher Strasse 1
> 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: 
> Feldkirchen bei Muenchen
> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas 
> Lusk
> Registergericht: Muenchen HRB 47456
> Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. 
> (BLZ 502 109 00) 600119052
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

Re: Quick question?

[Andrey Borzenkov]

В Mon, 9 Dec 2013 15:59:19 +0000
"Stojsavljevic, Zoran" <zoran.stojsavljevic@intel.com> пишет:

> Hello,
> 
> I see that grub-devel changed from bzr to git.
> 
> What will be the equivalent of: http://bzr.savannah.gnu.org/lh/grub/trunk/grub/changes ? This link does not work anymore.
> 

I think http://git.savannah.gnu.org/cgit/grub.git/log/ comes close.

> How to find what is the GRUB version, from the current snapshot taken from git (git clone git://git.savannah.gnu.org/grub.git)?
> 

Could you really do it from bzr checkout? Usually it is "git describe
HEAD" as long as project maintains release tags.

> Thank you,
> Zoran
> _______
> Most of The Time you should be "intel inside" to be capable to think "out of the box".
> 
> Intel GmbH
> Dornacher Strasse 1
> 85622 Feldkirchen/Muenchen, Deutschland
> Sitz der Gesellschaft: Feldkirchen bei Muenchen
> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
> Registergericht: Muenchen HRB 47456
> Ust.-IdNr./VAT Registration No.: DE129385895
> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Quick question?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On 09.12.2013 16:59, Stojsavljevic, Zoran wrote:
> Hello,
> 
> I see that grub-devel changed from bzr to git.
> 
> What will be the equivalent of: http://bzr.savannah.gnu.org/lh/grub/trunk/grub/changes ? This link does not work anymore.
> 
> How to find what is the GRUB version, from the current snapshot taken from git (git clone git://git.savannah.gnu.org/grub.git)?
> 
Doesn't sounds like question for grub-devel or something you'd add
persons manually to CC.
> Thank you,
> Zoran
> _______
> Most of The Time you should be "intel inside" to be capable to think "out of the box".
> 
> Intel GmbH
> Dornacher Strasse 1
> 85622 Feldkirchen/Muenchen, Deutschland
> Sitz der Gesellschaft: Feldkirchen bei Muenchen
> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
> Registergericht: Muenchen HRB 47456
> Ust.-IdNr./VAT Registration No.: DE129385895
> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
> 
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Quick question?

[Stojsavljevic, Zoran]

Hello,

I see that grub-devel changed from bzr to git.

What will be the equivalent of: http://bzr.savannah.gnu.org/lh/grub/trunk/grub/changes ? This link does not work anymore.

How to find what is the GRUB version, from the current snapshot taken from git (git clone git://git.savannah.gnu.org/grub.git)?

Thank you,
Zoran
_______
Most of The Time you should be "intel inside" to be capable to think "out of the box".

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

Quick Question ..

[Gordon Henderson]

I'm just after conformation (or not!) of something I've done for a long
time which I think is right - it certainly seem right, but one of those
things I've always wondered about ...

When creating an array I allocate drives from alternative controllers with
the thought that the OS/system/hardware might be able to better overlap
accesses to the devices - but it sort of assumes that the kernel drivers
(and/or mdadm) don't re-order accesses to the devices internally (I'm not
counting SCSI logical re-ordering here)

So. eg. an example I'm working on now - I have a server with 2 external
facing SCSI interfaces, and a box with 14 drives on 2 chains - so 7 drives
on each interface (I'd prefer less, but it's what I've got - it's a Dell
external box)  sd{a-g} are on scsi0, and sd{h-n} are on scsi1, so I issue
the create command with:

  mdadm --create /dev/md1 -n14 -l6	\
	 /dev/sda /dev/sdh		\
	 /dev/sdb /dev/sdi		\
	etc.

I guess benchmarking it would be the way to really test it, but I'm not
after performance for this particular box - just after some thoughts as to
whether this is the "best" (or not!) way to do things, or if I'm wasting
my time doing it this way!

Thanks,

Gordon