Can you prove it? You mean it can supply more current? :)
> But tps65217C (in BBB) has a more power availability vs. tps65217B (in
BBW).



2013/11/20 Jakub Żymełka <[email protected]>

> Ok, I see.
> But tps65217C (in BBB) has a more power availability vs. tps65217B (in
> BBW).
> Reducing the CPU speed is not the solution. For example I would like to
> work with a clock speed of 1GHz.
>
> So, are You suggesting that the PMIC is incorrect?
> Can anyone else give an opinion? Maybe the designers of the new BBB?
>
> Best regards,
> Jakub.
>
>
> W dniu środa, 20 listopada 2013 08:42:18 UTC+1 użytkownik lisarden napisał:
>>
>> Jakub, answering to your question:
>> tps65217b is not tps65217b (bbb)
>> Bbw 600mhz vs bbb 1000mhz
>> Ddr2 pwr consumption != ddr3
>>
>> That is why when people reduce the cpu freq systems become stable, but I
>> don't think it can help because I run my board in cpu ondemand governor and
>> it still reboots. However when running ezsdk my system seems to be stable
>> while on Ubuntu it reboots randomly
>> 20 нояб. 2013 г. 10:53 пользователь "Jakub Żymełka" <[email protected]>
>> написал:
>>
>> Lei Wang,
>>> yes, You can just use a wire to connect SYS_5V and VDD_5V after boot up.
>>> We've done this before we choose the option with the transistor.
>>>
>>> We are working on the 04.2013 U-boot, so we will try the newest version
>>> 10.2013 and I will let you know about my results.
>>>
>>> lisarden,
>>> According to you, the power management unit ( tps65217 ) in the BBB is
>>> not able to provide enough power by single pin?
>>> So why in the BBWhite or with the 3.8 kernel is no any random reboot?
>>> The PMIC is exactly the same...
>>>
>>>
>>>
>>> W dniu wtorek, 19 listopada 2013 20:05:34 UTC+1 użytkownik lisarden
>>> napisał:
>>>>
>>>> this issue can probably be because tps65217 simply can't handle too
>>>> much current through a single pin. If an internal switch AC|USB=SYS get
>>>> overheated then it can just shutdown to avoid a system damage
>>>>
>>>>
>>>> 2013/11/19 Lei Wang <[email protected]>
>>>>
>>>>> The time jumping issue seems to relate to u-boot per Robert Nelson's
>>>>> suggestion (https://groups.google.com/forum/#!category-topic/
>>>>> beagleboard/beaglebone-black/xPxzYyNsA78). I dropped in a newer
>>>>> u-boot images. It seems to fix the problem.
>>>>>
>>>>> For the random reboots, I limited the CPU clock frequency to 500MHz.
>>>>> It seems that the board is running more robust. So far I didn't see any
>>>>> random reboot. However I still don't understand why it seems that Angstrom
>>>>> or 3.8 Android images make the difference.
>>>>>
>>>>> Connect SYS_5V and VDD_5V? Since I noticed by connecting the board to
>>>>> a USB port (i.e. adb) seems to stop the random reboot, I wonder if it has
>>>>> something to do with VDD_5V and SYS_5V. I will do a little bit more 
>>>>> digging
>>>>> into the schematic.
>>>>>
>>>>> For test purpose can I just use a wire to connect SYS_5V and VDD_5V
>>>>> after boot up?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Lei
>>>>>
>>>>>
>>>>> On Tuesday, November 19, 2013 6:38:49 AM UTC-5, Jakub Żymełka wrote:
>>>>>>
>>>>>> My BBB is A5C version. We've tested more than 10 pcs BBB and all of
>>>>>> it has the same problem...
>>>>>> One, but not very elegant solution is to after start the board, make
>>>>>> a jumper between pins SYS_5V and VDD_5V, in example with any mosfet
>>>>>> transistor.
>>>>>> With this jumper, on kernel 3.2 there was no reset from the time of
>>>>>> three weeks.
>>>>>> Anybody have any other solutons? Because this cannot be the final.
>>>>>>
>>>>>> Best regards!
>>>>>> I look forward for suggestions!
>>>>>> Jakub.
>>>>>>
>>>>>>
>>>>>> W dniu piątek, 8 listopada 2013 05:12:08 UTC+1 użytkownik Lei Wang
>>>>>> napisał:
>>>>>>>
>>>>>>> I have the same problem with BBB running Android. I tested TI
>>>>>>> prebuilt Android JB4.2 image. We have two versions of BBBs (A5A and 
>>>>>>> A5C).
>>>>>>> Both of them have the issue.
>>>>>>>
>>>>>>> I posted my question on Ti e2e website: http://e2e.ti.com/sup
>>>>>>> port/embedded/android/f/509/p/297726/1049885.aspx#1049885
>>>>>>>
>>>>>>> However it seems that the problem goes away when I load Angstrom
>>>>>>> image (based on 3.8 kernel). Also if I use Andrew Henderson's
>>>>>>> Android image (also 3.8), the problem goes away. However we cannot use
>>>>>>> Andrew's image since there are a lot drivers are missing.
>>>>>>>
>>>>>>> I also have the time jump forward problem. The problem goes away
>>>>>>> when I switch to 3.8 kernel.
>>>>>>>
>>>>>>> Jakub, may I ask what version is your BBB?
>>>>>>>
>>>>>>>
>>>>>>> Lei
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wednesday, November 6, 2013 4:11:52 AM UTC-5, Jakub Żymełka wrote:
>>>>>>>>
>>>>>>>> There are no hints or any solutions...??
>>>>>>>> Please help!
>>>>>>>>
>>>>>>>> W dniu środa, 23 października 2013 13:09:00 UTC+2 użytkownik Jakub
>>>>>>>> Żymełka napisał:
>>>>>>>>>
>>>>>>>>> Hello!
>>>>>>>>> I have a problem. It is based on an involuntary resetting of the
>>>>>>>>> BBBlack.
>>>>>>>>> This happens occasionally. About once a day. Totally when you
>>>>>>>>> least expect it.
>>>>>>>>> This happens more often on higher frequencies ( 800Mhz, 1Ghz).
>>>>>>>>> On the console at the time of reset, nothing extra is displayed.
>>>>>>>>> No error's about kernel panic, sync, segmentation fault or another.
>>>>>>>>> Just like the same as if I pressed the reset button located on the
>>>>>>>>> board - but I DIDN'T!
>>>>>>>>> I'm working on Koenkoi's linux-kernel ti33x-psp-3.2.28-r16c-
>>>>>>>>> gitr720e07b4c1f687b61b147b31c698cb6816d72f01 + a few changes to
>>>>>>>>> run on the BBB.
>>>>>>>>> https://github.com/koenkooi/linux/archive/linux-ti33x-psp-3.
>>>>>>>>> 2.28-r16c+gitr720e07b4c1f687b61b147b31c698cb6816d72f01.zip
>>>>>>>>> Kernel is exactly the same as in the Angstrom release.
>>>>>>>>> I would add, that on the BBW nothing bad happens, everything is
>>>>>>>>> working properly.
>>>>>>>>> Anyone has already had a similar situation?
>>>>>>>>> If it is necessary I can send the kernel patch and configuration
>>>>>>>>> file.
>>>>>>>>>
>>>>>>>>> Best regards!
>>>>>>>>> I look forward for suggestions!
>>>>>>>>> Jakub.
>>>>>>>>>
>>>>>>>>  --
>>>>> For more options, visit http://beagleboard.org/discuss
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "BeagleBoard" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
>>>>  Company - http://www.linkedin.com/company/mentorel
>>>> Facebook - https://www.facebook.com/mentorel.company
>>>>
>>>  --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
Company - http://www.linkedin.com/company/mentorel
Facebook - https://www.facebook.com/mentorel.company

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to