Hi,
On 08/09/16 11:51, Siarhei Siamashka wrote:
> On Mon, 5 Sep 2016 09:23:00 +0100
> Andre Przywara wrote:
>
>> Hi,
>>
>> On 05/09/16 05:12, Siarhei Siamashka wrote:
>>> On Mon, 5 Sep 2016 01:32:38 +0100
>>> Andre Przywara wrote:
>>>
On Mon, 5 Sep 2016 09:23:00 +0100
Andre Przywara wrote:
> Hi,
>
> On 05/09/16 05:12, Siarhei Siamashka wrote:
> > On Mon, 5 Sep 2016 01:32:38 +0100
> > Andre Przywara wrote:
> >
> >> This commit moved the SPL stack into SRAM C, which worked
Hi,
On 05/09/16 05:12, Siarhei Siamashka wrote:
> On Mon, 5 Sep 2016 01:32:38 +0100
> Andre Przywara wrote:
>
>> This commit moved the SPL stack into SRAM C, which worked when the SPL
>> set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access
>> from the
On Mon, 5 Sep 2016 01:32:38 +0100
Andre Przywara wrote:
> This commit moved the SPL stack into SRAM C, which worked when the SPL
> set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access
> from the CPU.
> However booting with boot0 (and thus not using SPL
This commit moved the SPL stack into SRAM C, which worked when the SPL
set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access
from the CPU.
However booting with boot0 (and thus not using SPL at all) we still run
with a 200 MHz AHB1, so any access to SRAM C is prone to fail.
Since
5 matches
Mail list logo