Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Nov 2023 00:46:05 +0000
From:      Stanislav Silnicki <stanislav.silnicki@mailgate.us>
To:        "freebsd-arm" <freebsd-arm@freebsd.org>
Subject:   Re: STM32MP157
Message-ID:  <19de1a006e313.760d63ffe37aa@mailgate.us>
References:  <4d6bf0126f4fb.c24cc5f2fa47c@mailgate.us> <cade2176971ebe57c4cf952a633e12d5@ohdata.se> <00cab7929791c.8af55c0bd1d5f@mailgate.us> <5d65957f4c04a4bec7ae6ef5469b149c@ohdata.se> <d12e3b1a90216.8e6290090dd15@mailgate.us> <0dab0fc75864.77e1118ea80bb@mailgate.us> <5aa7e3eff95c.2102a80bb1a3b@mailgate.us> <0926803a4f0a.17799edcfe428@mailgate.us>

next in thread | previous in thread | raw e-mail | index | archive | help
------sinikael-?=_1-17003547656200.5932120312415674
Content-Type: text/plain; format=flowed
Content-Transfer-Encoding: 7bit

The root cause of zeroed stack in my setup with STM32MP157 seems to be in 
the TEX remapping registers values, calculated by pmap_set_tex(void). It 
can be a wrong assumption, as I'm not sure of any hardware (OTP/Security) 
tunings, that might be in effect....
Blindly copied values for PRRR & NMRR registers from Linux kernel (6.1.28), 
supplied by STM in their distribution I could avoid the trouble with zeroed 
stack memory. The hardcoded values are:
rg ".equ\s+(PR|NM)RR" arch/arm/mm/*
arch/arm/mm/proc-v7-3level.S
110:.equ PRRR, 0xeeaa4400 @ MAIR0
111:.equ NMRR, 0xff000004 @ MAIR1
arch/arm/mm/proc-v7-2level.S
137:.equ PRRR, 0xff0a81a8
138:.equ NMRR, 0x40e040e0
I (wrongly?) assume, 2level is related to the ones, calculated by 
pmap_set_tex.
Narrowing down the inconsistency among values found in Linux kernel and 
calculated here, I came to the result that the type of inner cache, tuned 
for first value of tex_classes lut ruins memory:
TEX(PRRR_MEM, NMRR_WB_WA, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - zeroes 
stack mem on TLB flush
TEX(PRRR_MEM, NMRR_WB, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - zeroes stack 
mem on TLB flush
TEX(PRRR_MEM, NMRR_WT, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - DOES NOT 
zeroes stack mem on TLB flush
TEX(PRRR_MEM, NMRR_NC, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - DOES NOT 
zeroes stack mem on TLB flush
Need further investigation....
Any clues?
Stan
Stanislav Silnicki wrote:
STM32MP15x port current progress:
... it took some time to solder down the probe and establish conveniences 
with remote kernel debug...
So far, I need to understand, whither or not I face an expected behavior?
It looks like tlb_flush_all_local() 
(https://github.com/freebsd/freebsd-src/blob/525ecfdad597980ea4cd59238e24c8530dbcd31d/sys/arm/arm/pmap-v6.c#L512C14-L512C14)

destroys stack memory, where return address is stored, so when stored lr is 
poped into pc, it is 0x0....
here is a dump of my debug session around that code:
508 cp15_prrr_set(prrr);
(kgdb) i f
Stack level 0, frame at 0xc0784598:
pc = 0xc0557b44 in pmap_set_tex (/usr/src/sys/arm/arm/pmap-v6.c:508); saved 
pc = 0xc055254c
called by frame at 0xc07847e0
source language c.
Arglist at 0xc0784590, args: 
Locals at 0xc0784590, Previous frame's sp is 0xc0784598
Saved registers:
r4 at 0xc0784580, r5 at 0xc0784584, r6 at 0xc0784588, r10 at 0xc078458c, 
r11 at 0xc0784590, lr at 0xc0784594
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) n
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
509 cp15_nmrr_set(nmrr);
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) n
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
512 tlb_flush_all_local();
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
_CP15_TLBIALL () at /usr/src/sys/arm/include/cpu-v6.h:147
147 _WF0(_CP15_TLBIALL, CP15_TLBIALL) /* Invalidate entire unified TLB */
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
tlb_flush_all_local () at /usr/src/sys/arm/include/cpu-v6.h:340
340 dsb();
(kgdb) x 0xc0784594
0xc0784594: 0x00000000
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513
513 }
(kgdb) si
Polling target stm32mp15x.cm4 failed, trying to reexamine
Failed to read memory at 0xe000ed00
Examination failed, GDB will be halted. Polling again in 100ms
Program stopped.
pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513
513 }
(kgdb) 
The address, referenced from error message (0xe000ed00) is mapped by STM's 
address space to "DDR extension (CA7 only) or Debug" with debug assigned to 
Cortex-M4 coprocessor.
I'm not sure, that it is an unexpected behav. (it is my first attempt to 
port to armv7), so need an advice.
Any?
Stan
Stanislav Silnicki wrote:
my current progress of STM32MP1xx port attempt:
Basically, both options to boot ubldr and then kernel in SPL & TF-A modes 
of u-boot are supported.
Initially, when I stated from TF-A options (security supervision from arm's 
trusted firmware os) I stuck with 
this line: 
https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371 
<https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371>; 

control does not seem to reach beyond that point. I tried to enable the led 
with this assembly, which works anywhere else:
/* prepare to use LED @ GPIOA 13*/
ldr r0, =0x50002014
ldr r1, =0xFFFFDFFF
ldr r2, [r0]
and r2, r1, r2
/* Enable caches. */
mrc CP15_SCTLR(r7)
orr r7, #CPU_CONTROL_DC_ENABLE
orr r7, #CPU_CONTROL_IC_ENABLE
orr r7, #CPU_CONTROL_BPRD_ENABLE
mcr CP15_SCTLR(r7)
DSB
/* turn on GPIO LED */
str r2, [r0]
Control passes if I disable data cache ORing instruction, but then hangs on 
setting of new TTB couple lines below...
I thought it was due to security access control from TF-A, but it behaves 
the same w/o.
Any clues or expertise from other platforms are highly appreciated.
Stan
Stanislav Silnicki wrote:
Hello, I need an advice on the intial addresses layout when booting the 
kernel.
As I understand, ubldr is the proper way to boot the kernel. 
What is the correct address to load it, given that I wand to keep default 
KERNVIRTADDR (=0xc0000000) intact?
The u-boot loads ubldr this way in my current setup:
// FreeBSD version of environment
env_set("baudrate", "115200");
env_set("console", "ttyS0,115200");
env_set("stderr", "serial");
env_set("stdin", "serial");
env_set("stdout", "serial");
env_set("autostart", "yes");
env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at 
index 1
env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf");
then ubldr leads the kernel from mmc and passes it the control:
Loading kernel...
/boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 
data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98|
Loading configured modules...
can't find '/boot/entropy'
can't find '/etc/hostid'
Using DTB compiled into kernel.
Kernel entry at 0xc0400200...
Kernel args: (null)
Then I could correctly pass the init of MMU and get into translated mode 
only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and 
loader clash somehow. 
So, just need to understand what is best option to load ubldr to? Will it 
affect further routines?
Stan
Stanislav Silnicki wrote:
OK, I got the idea!
As I realize, there is a minor bug in dtc, which affects compilation of 
stm's originated DTBs. I think it is best to make a PR into 
https://github.com/davidchisnall/dtc, 
<https://github.com/davidchisnall/dtc,>; which I'm discussing with repo 
owner already. Please tell me, that I need to post PR into FBSD source tree 
if it is a shorter way for my fix.
My current setup is based upon QBASE1 from Karo-Electronics, but there is 
no goal to support/debug all peripherals, only a subset, including USB, 
I2C, SDMMC, DSI (and GPU, if lucky).
https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf 
<https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf>; 

The vendor (Karo) supports only their Yocto based Linux distro. I spent 
some time to prepare TF-A & Uboot, capable with booting from SD card (that 
is more robust approach, as I think). STM does not promote/support 
non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it 
is pretty cumbersome path, I had to pass. I think, it will be easier for me 
to prepare some sort of README to support customization of uboot for STM's 
port and dig it somewhere in SRC rather than ; ; ; ;try to post PR's in 
those repos... Not sure, anyway.
So far I'm struggling with uart and early_printf...
I'm mixing this activity with my current occupation, so I don't expect 
rapid progress.
Thank you for clarifications! I'll try to do my best!
Stan
Oskar Holmlund wrote:
Hi Stanislav,
Please resend your message and CC the arm mailing list. It might be 
interesting for someone in the future ( 
https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think 
you stopped working on the STM32 port.
You should always keep one terminal up n running % man 9 style :)
https://wiki.freebsd.org/Phabricator will give you some information.
Its good if you get to know the people active in the ARM area, just keep an 
eye on the mailinglist and you will notice some names. If you have the 
opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, 
bsdcan.org) to get to know even more people.
Join the IRC, for example on efnet #bsdmips is a good channel for ARM 
stuff.
Start with small changes and you will get feedback. From there the 
experience will grow and you will get into it all.
Correct, the device-tree import is from the Linux kernel and there is no 
prior work for the STM32MP15 SoCs. I cant find anything about the 
STM32MP15x in Net or OpenBSD either.
Probably because the STM32MP15 is the first(?) application SoC from ST?
1) hum? Do you need that for the reviews? It should be in SRC
2) Target branch is probably main.
3) It depends, if your custom board is opensource and availble around the 
globe through mouser/farnell/.. I dont see any problem. Otherwise pick the 
board from ST that you used as a reference when you developed the custom 
board.
For example in my day job we have a custom board built around the 
octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black 
wifi. So the code thats goes into the FreeBSD project are all tested on the 
beaglebone boards. The stuff we need for our custom board like the device 
tree is keept as local patches in our inhouse build process.
//Oskar
2023-10-28 14:25 skrev Stanislav Silnicki:
Hi Oskar!
 > can you point me some guidelines to help myself to fit development
process? I'm sure, there is mature dev. culture around FBSD and I'd be
happy to make my contribution coherently from the beginning.
 > So far I'm done with setup of my account at reviews (keys, 2FA, etc.)
 > As I understand, there is no considerable progress with STM32,
although I have noticed, there are some DTS imported into the project.
 > > Indeed, several major questions:
1. repo url?
2. tagret branch for patches for stm32 hw?
3. is it possible to target custom board from our project, or I have
to ensure support for all dev. boards, provided by STM?
 > Thank you,Stan
 > Oskar Holmlund wrote:
 >> 2023-10-27 22:33 skrev Stanislav Silnicki:
<block
quote class="gmail_quote" type="cite" style="margin:0 0 0 
.8ex;border-left:1px #ccc solid;padding-left:1ex">
 >>> Hello!
I'm porting onto the subject hardware. So far the progress is
modest,
while the system boots (without console although...)
One of major issues is hardcoded value inside locore-v6.S. Here
is my
relevant post:
 >> > 
https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438

[1]
What is the best way to proceed? Patch, vendor kernel build,
something
else?
Stan
 > Links:
------
 >> [1] >
 > 
https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
 
>> Hi Stan,
 >> Upload your patch to reviews.freebsd.org
 >> Love to see your other patches for the STM32MP15x.
kquote>
</block
 >> //Oskar

------sinikael-?=_1-17003547656200.5932120312415674
Content-Type: text/html; format=flowed
Content-Transfer-Encoding: 7bit

<html><head></head><body><div>
                    
     
     
       
         <meta charset="utf-8">
       
       
         <div id="compose-body-wrapper" dir="auto"><div dir="auto" 
id="tmjah_g_1299">The root cause of zeroed stack in my setup with 
STM32MP157 seems to be in the TEX remapping registers values, calculated 
by&nbsp; pmap_set_tex(void). It can be a wrong assumption, as I'm not sure 
of any hardware (OTP/Security) tunings, that might be in 
effect....</div><div dir="auto" id="tmjah_g_1299"><br></div><div dir="auto" 
id="tmjah_g_1299">Blindly copied values for PRRR &amp; NMRR registers from 
Linux kernel (6.1.28), supplied by STM in their distribution I could avoid 
the trouble with zeroed stack memory. The hardcoded values are:</div><div 
dir="auto" id="tmjah_g_1299"><div dir="auto" id="tmjah_g_1299"><div 
dir="auto" id="tmjah_g_1299">rg ".equ\s+(PR|NM)RR" arch/arm/mm/*</div><div 
dir="auto" id="tmjah_g_1299">arch/arm/mm/proc-v7-3level.S</div><div 
dir="auto" id="tmjah_g_1299">110:.equ<span style="white-space:pre">	
</span>PRRR,<span style="white-space:pre">	</span>0xeeaa4400<span 
style="white-space:pre">			</span>@ MAIR0</div><div dir="auto" 
id="tmjah_g_1299">111:.equ<span style="white-space:pre">	</span>NMRR,<span 
style="white-space:pre">	</span>0xff000004<span style="white-space:pre">			
</span>@ MAIR1</div><div dir="auto" id="tmjah_g_1299"><br></div><div 
dir="auto" id="tmjah_g_1299">arch/arm/mm/proc-v7-2level.S</div><div 
dir="auto" id="tmjah_g_1299">137:.equ<span style="white-space:pre">	
</span>PRRR,<span style="white-space:pre">	</span>0xff0a81a8</div><div 
dir="auto" id="tmjah_g_1299">138:.equ<span style="white-space:pre">	
</span>NMRR,<span style="white-space:pre">	
</span>0x40e040e0</div><div><br></div><div>I (wrongly?) assume, 2level is 
related to the ones, calculated by 
pmap_set_tex.</div><div><br></div><div>Narrowing down 
the&nbsp;inconsistency among values found in Linux kernel and calculated 
here, I came to the result that the type of inner cache, tuned for first 
value of tex_classes lut ruins memory:</div><div><div><span 
style="white-space:pre"><br></span></div><div><span 
style="white-space:pre">	</span>TEX(PRRR_MEM, NMRR_WB_WA,&nbsp; &nbsp; 
NMRR_WB_WA, 0),&nbsp; /* 0 - ATTR_WB_WA<span style="white-space:pre">	
</span>*/ - zeroes stack mem on TLB flush</div></div><div><div><span 
style="white-space: pre;"><br></span></div><div><span style="white-space: 
pre;">	</span>TEX(PRRR_MEM, NMRR_WB,&nbsp; &nbsp; NMRR_WB_WA, 0),&nbsp; /* 
0 - ATTR_WB_WA<span style="white-space: pre;">	</span>*/ - zeroes stack mem 
on TLB flush</div><div><div><span style="white-space: pre;">	
</span>TEX(PRRR_MEM, NMRR_WT,&nbsp; &nbsp; NMRR_WB_WA, 0),&nbsp; /* 0 - 
ATTR_WB_WA<span style="white-space: pre;">	</span>*/ - DOES NOT zeroes 
stack mem on TLB flush</div><div><div><span style="white-space: pre;">	
</span>TEX(PRRR_MEM, NMRR_NC,&nbsp; &nbsp; NMRR_WB_WA, 0),&nbsp; /* 0 - 
ATTR_WB_WA<span style="white-space: pre;">	</span>*/ - DOES NOT zeroes 
stack mem on TLB flush</div><div><br></div><div>Need further 
investigation....</div></div></div></div><div>Any 
clues?</div><div><br></div><div>Stan</div></div></div><br></div><div 
class="replyHeader" dir="auto">Stanislav Silnicki 
wrote:</div><br><div><blockquote 
cite="mid:0926803a4f0a.17799edcfe428@mailgate.us" type="cite" 
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
                                              <meta charset="utf-8">
                       <div id="compose-body-wrapper" dir="auto"><div 
dir="auto">STM32MP15x port current progress:</div><div 
dir="auto"><br></div><div dir="auto">... it took some time to solder down 
the probe and establish conveniences with remote kernel debug...</div><div 
dir="auto"><br></div><div dir="auto">So far, I need to understand, whither 
or not I face an expected behavior?</div><div dir="auto"><br></div><div 
dir="auto">It looks like tlb_flush_all_local() 
(https://github.com/freebsd/freebsd-src/blob/525ecfdad597980ea4cd59238e24c8530dbcd31d/sys/arm/arm/pmap-v6.c#L512C14-L512C14)</div><div 
dir="auto">destroys stack memory, where return address is stored, so when 
stored lr is poped into pc, it is 0x0....</div><div 
dir="auto"><br></div><div dir="auto">here is a dump of my debug session 
around that code:</div><div dir="auto"><br></div><div dir="auto"><div 
dir="auto"><div dir="auto"><span style="font-size: 12px;">508</span><span 
style="white-space: pre; font-size: 12px;">		</span><span style="font-size: 
12px;">cp15_prrr_set(prrr);</span></div><div dir="auto"><span 
style="font-size: 12px;">(kgdb) i f</span></div><div dir="auto"><span 
style="font-size: 12px;">Stack level 0, frame at 
0xc0784598:</span></div><div dir="auto"><span style="font-size: 
12px;">&nbsp;pc = 0xc0557b44 in pmap_set_tex 
(/usr/src/sys/arm/arm/pmap-v6.c:508); saved pc = 
0xc055254c</span></div><div dir="auto"><span style="font-size: 
12px;">&nbsp;called by frame at 0xc07847e0</span></div><div 
dir="auto"><span style="font-size: 12px;">&nbsp;source language 
c.</span></div><div dir="auto"><span style="font-size: 12px;">&nbsp;Arglist 
at 0xc0784590, args:&nbsp;</span></div><div dir="auto"><span 
style="font-size: 12px;">&nbsp;Locals at 0xc0784590, Previous frame's sp is 
0xc0784598</span></div><div dir="auto"><span style="font-size: 
12px;">&nbsp;Saved registers:</span></div><div dir="auto"><span 
style="font-size: 12px;">&nbsp; r4 at 0xc0784580, r5 at 0xc0784584, r6 at 
0xc0784588, r10 at 0xc078458c, r11 at 0xc0784590, lr at 
0xc0784594</span></div><div dir="auto"><span style="font-size: 
12px;">(kgdb) x 0xc0784594</span></div><div dir="auto"><span style=""><span 
style="font-size: 12px;">0xc0784594:</span><span style="white-space: pre; 
font-size: 12px;">	</span><span style="font-size: 
12px;">0xc055254c</span></span></div><div dir="auto"><span 
style="font-size: 12px;">(kgdb) n</span></div><div dir="auto"><span 
style="font-size: 12px;">stm32mp15x.cpu0 rev 5, partnum c07, arch f, 
variant 0, implementor 41</span></div><div dir="auto"><span 
style="font-size: 12px;">stm32mp15x.cpu1 rev 5, partnum c07, arch f, 
variant 0, implementor 41</span></div><div dir="auto"><span 
style="font-size: 12px;">target halted in Thumb state due to debug-request, 
current mode: Supervisor</span></div><div dir="auto"><span 
style="font-size: 12px;">cpsr: 0x600001f3 pc: 0x0000060e</span></div><div 
dir="auto"><span style="font-size: 12px;">MMU: disabled, D-Cache: disabled, 
I-Cache: enabled</span></div><div dir="auto"><span style="font-size: 
12px;">509</span><span style="white-space: pre; font-size: 12px;">		
</span><span style="font-size: 12px;">cp15_nmrr_set(nmrr);</span></div><div 
dir="auto"><span style="font-size: 12px;">(kgdb) x 
0xc0784594</span></div><div dir="auto"><span style="font-size: 
12px;">0xc0784594:</span><span style="white-space: pre; font-size: 12px;">	
</span><span style="font-size: 12px;">0xc055254c</span></div><div 
dir="auto"><span style="font-size: 12px;">(kgdb) n</span></div><div 
dir="auto"><span style="font-size: 12px;">stm32mp15x.cpu0 rev 5, partnum 
c07, arch f, variant 0, implementor 41</span></div><div dir="auto"><span 
style="font-size: 12px;">stm32mp15x.cpu1 rev 5, partnum c07, arch f, 
variant 0, implementor 41</span></div><div dir="auto"><span 
style="font-size: 12px;">target halted in Thumb state due to debug-request, 
current mode: Supervisor</span></div><div dir="auto"><span 
style="font-size: 12px;">cpsr: 0x600001f3 pc: 0x0000060e</span></div><div 
dir="auto"><span style="font-size: 12px;">MMU: disabled, D-Cache: disabled, 
I-Cache: enabled</span></div><div dir="auto"><span style="font-size: 
12px;">512</span><span style="white-space: pre; font-size: 12px;">		
</span><span style="font-size: 
12px;">tlb_flush_all_local();</span></div><div dir="auto"><span 
style="font-size: 12px;">(kgdb) x 0xc0784594</span></div><div 
dir="auto"><font color="#9c0000" style=""><span style="font-size: 
12px;">0xc0784594:</span><span style="white-space: pre; font-size: 12px;">	
</span><span style="font-size: 12px;">0xc055254c</span></font></div><div 
dir="auto"><span style="font-size: 12px;">(kgdb) si</span></div><div 
dir="auto"><span style="font-size: 12px;">stm32mp15x.cpu0 rev 5, partnum 
c07, arch f, variant 0, implementor 41</span></div><div dir="auto"><span 
style="font-size: 12px;">stm32mp15x.cpu1 rev 5, partnum c07, arch f, 
variant 0, implementor 41</span></div><div dir="auto"><span 
style="font-size: 12px;">target halted in Thumb state due to debug-request, 
current mode: Supervisor</span></div><div dir="auto"><span 
style="font-size: 12px;">cpsr: 0x600001f3 pc: 0x0000060e</span></div><div 
dir="auto"><span style="font-size: 12px;">MMU: disabled, D-Cache: disabled, 
I-Cache: enabled</span></div><div dir="auto"><span style="font-size: 
12px;">_CP15_TLBIALL () at 
/usr/src/sys/arm/include/cpu-v6.h:147</span></div><div dir="auto"><span 
style="font-size: 12px;">147</span><span style="white-space: pre; 
font-size: 12px;">	</span><span style="font-size: 
12px;">_WF0(_CP15_TLBIALL, CP15_TLBIALL)</span><span style="white-space: 
pre; font-size: 12px;">		</span><span style="font-size: 12px;">/* 
Invalidate entire unified TLB */</span></div><div dir="auto"><span 
style="font-size: 12px;">(kgdb) si</span></div><div dir="auto"><span 
style="font-size: 12px;">stm32mp15x.cpu0 rev 5, partnum c07, arch f, 
variant 0, implementor 41</span></div><div dir="auto"><span 
style="font-size: 12px;">stm32mp15x.cpu1 rev 5, partnum c07, arch f, 
variant 0, implementor 41</span></div><div dir="auto"><span 
style="font-size: 12px;">target halted in Thumb state due to debug-request, 
current mode: Supervisor</span></div><div dir="auto"><span 
style="font-size: 12px;">cpsr: 0x600001f3 pc: 0x0000060e</span></div><div 
dir="auto"><span style="font-size: 12px;">MMU: disabled, D-Cache: disabled, 
I-Cache: enabled</span></div><div dir="auto"><span style="font-size: 
12px;">tlb_flush_all_local () at 
/usr/src/sys/arm/include/cpu-v6.h:340</span></div><div dir="auto"><span 
style="font-size: 12px;">340</span><span style="white-space: pre; 
font-size: 12px;">		</span><span style="font-size: 
12px;">dsb();</span></div><div dir="auto"><span style="font-size: 
12px;">(kgdb) x 0xc0784594</span></div><div dir="auto"><span style=""><span 
style="font-size: 12px;">0xc0784594:</span><span style="white-space: pre; 
font-size: 12px;">	</span><span style="font-size: 
12px;">0x00000000</span></span></div><div dir="auto"><span 
style="font-size: 12px;">(kgdb) si</span></div><div dir="auto"><span 
style="font-size: 12px;">stm32mp15x.cpu0 rev 5, partnum c07, arch f, 
variant 0, implementor 41</span></div><div dir="auto"><span 
style="font-size: 12px;">stm32mp15x.cpu1 rev 5, partnum c07, arch f, 
variant 0, implementor 41</span></div><div dir="auto"><span 
style="font-size: 12px;">target halted in Thumb state due to debug-request, 
current mode: Supervisor</span></div><div dir="auto"><span 
style="font-size: 12px;">cpsr: 0x600001f3 pc: 0x0000060e</span></div><div 
dir="auto"><span style="font-size: 12px;">MMU: disabled, D-Cache: disabled, 
I-Cache: enabled</span></div><div dir="auto"><span style="font-size: 
12px;">pmap_set_tex () at 
/usr/src/sys/arm/arm/pmap-v6.c:513</span></div><div dir="auto"><span 
style="font-size: 12px;">513</span><span style="white-space: pre; 
font-size: 12px;">	</span><span style="font-size: 12px;">}</span></div><div 
dir="auto"><span style="font-size: 12px;">(kgdb) si</span></div><div 
dir="auto"><span style="font-size: 12px;">Polling target stm32mp15x.cm4 
failed, trying to reexamine</span></div><div dir="auto"><span 
style="font-size: 12px;">Failed to read memory at 
0xe000ed00</span></div><div dir="auto"><span style="font-size: 
12px;">Examination failed, GDB will be halted. Polling again in 
100ms</span></div><div dir="auto"><br></div><div dir="auto"><span 
style="font-size: 12px;">Program stopped.</span></div><div dir="auto"><span 
style="font-size: 12px;">pmap_set_tex () at 
/usr/src/sys/arm/arm/pmap-v6.c:513</span></div><div dir="auto"><span 
style="font-size: 12px;">513</span><span style="white-space: pre; 
font-size: 12px;">	</span><span style="font-size: 12px;">}</span></div><div 
dir="auto"><span style="font-size: 
12px;">(kgdb)&nbsp;</span></div><div><br></div></div></div><div dir="auto" 
id="tmjah_g_1299">The address, referenced from error message (0xe000ed00) 
is mapped by STM's address space to "DDR extension (CA7 only) or Debug" 
with debug assigned to Cortex-M4 coprocessor.</div><div dir="auto" 
id="tmjah_g_1299"><br></div><div dir="auto" id="tmjah_g_1299">I'm not sure, 
that it is an unexpected behav. (it is my first attempt to port to armv7), 
so need an advice.</div><div dir="auto" id="tmjah_g_1299">Any?</div><div 
dir="auto" id="tmjah_g_1299"><br></div><div dir="auto" 
id="tmjah_g_1299">Stan</div><div dir="auto" 
id="tmjah_g_1299"><br></div><br></div><div class="replyHeader" 
dir="auto"><span style="font-size: 12px;">Stanislav Silnicki 
wrote:</span></div><br><div><blockquote 
cite="mid:5aa7e3eff95c.2102a80bb1a3b@mailgate.us" type="cite" 
style="margin:0 0 0 .8ex;border-left:1px #ccc 
solid;padding-left:1ex"><div><span style="font-size: 12px;">                
           </span><meta charset="utf-8">
                       <div>
                                              <meta charset="utf-8">
                       <div id="compose-body-wrapper" dir="auto"><div 
dir="auto">my current progress of STM32MP1xx port attempt:</div><div 
dir="auto"><br></div><div dir="auto">Basically, both options to boot ubldr 
and then kernel in SPL &amp; TF-A modes of u-boot are supported.</div><div 
dir="auto"><br></div><div dir="auto">Initially, when I stated from TF-A 
options (security supervision from arm's trusted firmware os) I stuck 
with&nbsp;</div><div dir="auto">this line:&nbsp;<a 
href="https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371" 
target="_blank" style="font-family: Roboto; font-weight: 
400;">https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371</a></div><div 
dir="auto"><br></div><div dir="auto">control does not seem to reach beyond 
that point. I tried to enable the led with this assembly, which works 
anywhere else:</div><div dir="auto"><br></div><div dir="auto"><div 
dir="auto"><div dir="auto">&nbsp; &nbsp; /* prepare to use LED @ GPIOA 
13*/</div><div dir="auto">&nbsp; &nbsp; ldr r0, =0x50002014</div><div 
dir="auto">&nbsp; &nbsp; ldr r1, =0xFFFFDFFF</div><div dir="auto">&nbsp; 
&nbsp; ldr r2, [r0]</div><div dir="auto">&nbsp; &nbsp; and r2, r1, 
r2</div><div dir="auto"><br></div><div dir="auto"><span 
style="white-space:pre">	</span>/* Enable caches. */</div><div 
dir="auto"><span style="white-space:pre">	</span>mrc<span 
style="white-space:pre">	</span>CP15_SCTLR(r7)</div><div dir="auto"><span 
style="white-space:pre">	</span>orr<span style="white-space:pre">	
</span>r7, #CPU_CONTROL_DC_ENABLE</div><div dir="auto"><span 
style="white-space:pre">	</span>orr<span style="white-space:pre">	
</span>r7, #CPU_CONTROL_IC_ENABLE</div><div dir="auto"><span 
style="white-space:pre">	</span>orr<span style="white-space:pre">	
</span>r7, #CPU_CONTROL_BPRD_ENABLE</div><div dir="auto"><span 
style="white-space:pre">	</span>mcr<span style="white-space:pre">	
</span>CP15_SCTLR(r7)</div><div dir="auto"><span style="white-space:pre">	
</span>DSB</div><div dir="auto"><br></div><div dir="auto">&nbsp; &nbsp; /* 
turn on GPIO LED */</div><div dir="auto">&nbsp; &nbsp; str r2, 
[r0]</div><div><br></div><div>Control passes if I disable data cache ORing 
instruction, but then hangs on setting of new TTB couple lines 
below...</div><div><br></div><div>I thought it was due to security access 
control from TF-A, but it behaves the same 
w/o.</div><div><br></div><div>Any clues or expertise from other platforms 
are highly 
appreciated.</div><div><br></div><div>Stan</div></div></div><br></div><div 
class="replyHeader" dir="auto">Stanislav Silnicki wrote:</div><div 
class="replyHeader" dir="auto"><br></div><div><blockquote 
cite="mid:0dab0fc75864.77e1118ea80bb@mailgate.us" type="cite" 
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
                                              <meta charset="utf-8">
                       <div id="compose-body-wrapper" dir="auto"><div 
dir="auto">Hello, I need an advice on the intial addresses layout when 
booting the kernel.</div><div dir="auto"><br></div><div dir="auto">As I 
understand, ubldr is the proper way to boot the kernel. </div><div 
dir="auto">What is the correct address to load it, given that I wand to 
keep default KERNVIRTADDR (=0xc0000000) intact?</div><div 
dir="auto"><br></div><div dir="auto">The u-boot loads ubldr this way in my 
current setup:</div><div dir="auto"><div dir="auto"><br></div><div 
dir="auto"><font color="#397b21">&nbsp; // FreeBSD version of 
environment</font></div><div dir="auto"><font color="#397b21">&nbsp; 
env_set("baudrate", "115200");</font></div><div dir="auto"><font 
color="#397b21">&nbsp; env_set("console", "ttyS0,115200");</font></div><div 
dir="auto"><font color="#397b21">&nbsp; env_set("stderr", 
"serial");</font></div><div dir="auto"><font color="#397b21">&nbsp; 
env_set("stdin", "serial");</font></div><div dir="auto"><font 
color="#397b21">&nbsp; env_set("stdout", "serial");</font></div><div 
dir="auto"><font color="#397b21">&nbsp; env_set("autostart", 
"yes");</font></div><div dir="auto"><font color="#397b21">&nbsp; 
env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at 
index 1</font></div><div dir="auto"><font color="#397b21">&nbsp; 
env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr &amp;&amp; 
bootelf");</font></div><div dir="auto"><br></div><div dir="auto">then ubldr 
leads the kernel from mmc and passes it the control:</div><div 
dir="auto"><div dir="auto"><br></div><div dir="auto">Loading 
kernel...</div><div dir="auto">/boot/kernel/kernel text=0x1b4 text=0x5b8530 
text=0x17d91c data=0xa4a60 data=0x0+0x20c000 
0x4+0x88810+0x4+0xe9d98|</div><div dir="auto">Loading configured 
modules...</div><div dir="auto">can't find '/boot/entropy'</div><div 
dir="auto">can't find '/etc/hostid'</div><div dir="auto">Using DTB compiled 
into kernel.</div><div dir="auto">Kernel entry at 0xc0400200...</div><div 
dir="auto">Kernel args: (null)</div><div><br></div><div>Then I could 
correctly pass the init of MMU and get into translated mode only with 
setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash 
somehow. </div><div><br></div><div>So, just need to understand what is best 
option to load ubldr to? Will it affect further 
routines?<br></div><div><br></div><div>Stan</div></div><div 
dir="auto"><br></div></div><br></div><div class="replyHeader" 
dir="auto">Stanislav Silnicki wrote:</div><br><br><div><blockquote 
cite="mid:d12e3b1a90216.8e6290090dd15@mailgate.us" type="cite" 
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
                                              <meta charset="utf-8">
                       <div id="compose-body-wrapper" dir="auto"><div 
dir="auto"><div dir="auto" style="font-family: &quot;Open Sans&quot;, 
-apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, &quot;Helvetica 
Neue&quot;, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe 
UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; font-size: 
14px;">OK,&nbsp;<wbr>I&nbsp;<wbr>got&nbsp;<wbr>the&nbsp;<wbr>idea!<wbr></div><div 
dir="auto" style="font-family: &quot;Open Sans&quot;, -apple-system, 
BlinkMacSystemFont, &quot;Segoe UI&quot;, &quot;Helvetica Neue&quot;, 
Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI 
Emoji&quot;, &quot;Segoe UI Symbol&quot;; font-size: 14px;"><br></div><div 
dir="auto" style="font-family: &quot;Open Sans&quot;, -apple-system, 
BlinkMacSystemFont, &quot;Segoe UI&quot;, &quot;Helvetica Neue&quot;, 
Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI 
Emoji&quot;, &quot;Segoe UI Symbol&quot;; font-size: 
14px;"><wbr>As&nbsp;<wbr>I&nbsp;<wbr>realize,&nbsp;<wbr>there&nbsp;<wbr>is&nbsp;<wbr>a&nbsp;<wbr>minor&nbsp;<wbr>bug&nbsp;<wbr>in&nbsp;<wbr>dtc,&nbsp;<wbr>which&nbsp;<wbr>affects&nbsp;<wbr>compilation&nbsp;<wbr>of&nbsp;<wbr>stm's&nbsp;<wbr>originated&nbsp;<wbr>DTBs.&nbsp;<wbr>I&nbsp;<wbr>think&nbsp;<wbr>it&nbsp;<wbr>is&nbsp;<wbr>best&nbsp;<wbr>to&nbsp;<wbr>make&nbsp;<wbr>a&nbsp;<wbr>PR&nbsp;<wbr>into&nbsp;<wbr><a 
href="https://github.com/davidchisnall/dtc," target="_blank" rel="noopener 
noreferrer" title="https://github.com/davidchisnall/dtc," 
style="font-family: Roboto; font-weight: 
400;">https://github.com/davidchisnall/dtc,</a>&nbsp;<wbr>which&nbsp;<wbr>I'm&nbsp;<wbr>discussing&nbsp;<wbr>with&nbsp;<wbr>repo&nbsp;<wbr>owner&nbsp;<wbr>already.&nbsp;<wbr>Please&nbsp;<wbr>tell&nbsp;<wbr>me,&nbsp;<wbr>that&nbsp;<wbr>I&nbsp;<wbr>need&nbsp;<wbr>to&nbsp;<wbr>post&nbsp;<wbr>PR&nbsp;<wbr>into&nbsp;<wbr>FBSD&nbsp;<wbr>source&nbsp;<wbr>tree&nbsp;<wbr>if&nbsp;<wbr>it&nbsp;<wbr>is&nbsp;<wbr>a&nbsp;<wbr>shorter&nbsp;<wbr>way&nbsp;<wbr>for&nbsp;<wbr>my&nbsp;<wbr>fix.<wbr><br></div><div 
id="tmjah_g_1299" dir="auto" style="font-family: &quot;Open Sans&quot;, 
-apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, &quot;Helvetica 
Neue&quot;, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe 
UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; font-size: 
14px;"><br></div><div id="tmjah_g_1299" dir="auto" style="font-family: 
&quot;Open Sans&quot;, -apple-system, BlinkMacSystemFont, &quot;Segoe 
UI&quot;, &quot;Helvetica Neue&quot;, Arial, sans-serif, &quot;Apple Color 
Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; 
font-size: 
14px;"><wbr>My&nbsp;<wbr>current&nbsp;<wbr>setup&nbsp;<wbr>is&nbsp;<wbr>based&nbsp;<wbr>upon&nbsp;<wbr>QBASE1&nbsp;<wbr>from&nbsp;<wbr>Karo-<wbr>Electronics,&nbsp;<wbr>but&nbsp;<wbr>there&nbsp;<wbr>is&nbsp;<wbr>no&nbsp;<wbr>goal&nbsp;<wbr>to&nbsp;<wbr>support/<wbr>debug&nbsp;<wbr>all&nbsp;<wbr>peripherals,&nbsp;<wbr>only&nbsp;<wbr>a&nbsp;<wbr>subset,&nbsp;<wbr>including&nbsp;<wbr>USB,&nbsp;<wbr>I2C,&nbsp;<wbr>SDMMC,&nbsp;<wbr>DSI 
(<wbr>and&nbsp;<wbr>GPU,&nbsp;<wbr>if&nbsp;<wbr>lucky).<wbr></div><div 
id="tmjah_g_1299" dir="auto" style="font-family: &quot;Open Sans&quot;, 
-apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, &quot;Helvetica 
Neue&quot;, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe 
UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; font-size: 14px;"><a 
href="https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf" 
target="_blank" rel="noopener noreferrer" 
title="https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf">https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf</a></div><div 
id="tmjah_g_1299" dir="auto" style="font-family: &quot;Open Sans&quot;, 
-apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, &quot;Helvetica 
Neue&quot;, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe 
UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; font-size: 
14px;"><br></div><div id="tmjah_g_1299" dir="auto" style="font-family: 
&quot;Open Sans&quot;, -apple-system, BlinkMacSystemFont, &quot;Segoe 
UI&quot;, &quot;Helvetica Neue&quot;, Arial, sans-serif, &quot;Apple Color 
Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; 
font-size: 14px;"><wbr>The&nbsp;<wbr>vendor 
(<wbr>Karo)&nbsp;<wbr>supports&nbsp;<wbr>only&nbsp;<wbr>their&nbsp;<wbr>Yocto&nbsp;<wbr>based&nbsp;<wbr>Linux&nbsp;<wbr>distro.&nbsp;<wbr>I&nbsp;<wbr>spent&nbsp;<wbr>some&nbsp;<wbr>time&nbsp;<wbr>to&nbsp;<wbr>prepare&nbsp;<wbr>TF-<wbr>A 
&amp;&nbsp;<wbr>Uboot,&nbsp;<wbr>capable&nbsp;<wbr>with&nbsp;<wbr>booting&nbsp;<wbr>from&nbsp;<wbr>SD&nbsp;<wbr>card 
(<wbr>that&nbsp;<wbr>is&nbsp;<wbr>more&nbsp;<wbr>robust&nbsp;<wbr>approach,&nbsp;<wbr>as&nbsp;<wbr>I&nbsp;<wbr>think).&nbsp;<wbr>STM&nbsp;<wbr>does&nbsp;<wbr>not&nbsp;<wbr>promote/<wbr>support&nbsp;<wbr>non-<wbr>secure&nbsp;<wbr>boot&nbsp;<wbr>approach&nbsp;<wbr>with&nbsp;<wbr>SPL,&nbsp;<wbr>they&nbsp;<wbr>insist&nbsp;<wbr>to&nbsp;<wbr>use&nbsp;<wbr>TF-<wbr>A&nbsp;<wbr>or&nbsp;<wbr>OPTEE,&nbsp;<wbr>so&nbsp;<wbr>it&nbsp;<wbr>is&nbsp;<wbr>pretty&nbsp;<wbr>cumbersome&nbsp;<wbr>path,&nbsp;<wbr>I&nbsp;<wbr>had&nbsp;<wbr>to&nbsp;<wbr>pass.&nbsp;<wbr>I&nbsp;<wbr>think,&nbsp;<wbr>it&nbsp;<wbr>will&nbsp;<wbr>be&nbsp;<wbr>easier&nbsp;<wbr>for&nbsp;<wbr>me&nbsp;<wbr>to&nbsp;<wbr>prepare&nbsp;<wbr>some&nbsp;<wbr>sort&nbsp;<wbr>of&nbsp;<wbr>README&nbsp;<wbr>to&nbsp;<wbr>support&nbsp;<wbr>customization&nbsp;<wbr>of&nbsp;<wbr>uboot&nbsp;<wbr>for&nbsp;<wbr>STM's&nbsp;<wbr>port&nbsp;<wbr>and&nbsp;<wbr>dig&nbsp;<wbr>it&nbsp;<wbr>somewhere&nbsp;<wbr>in&nbsp;<wbr>SRC&nbsp;<wbr>rather&nbsp;<wbr>than&nbsp
 ;

;

;

;

;<wbr>try&nbsp;<wbr>to&nbsp;<wbr>post&nbsp;<wbr>PR's&nbsp;<wbr>in&nbsp;<wbr>those&nbsp;<wbr>repos...&nbsp;<wbr>Not&nbsp;<wbr>sure,&nbsp;<wbr>anyway.<wbr></div><div 
id="tmjah_g_1299" dir="auto" style="font-family: &quot;Open Sans&quot;, 
-apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, &quot;Helvetica 
Neue&quot;, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe 
UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; font-size: 
14px;"><br></div><div id="tmjah_g_1299" dir="auto" style="font-family: 
&quot;Open Sans&quot;, -apple-system, BlinkMacSystemFont, &quot;Segoe 
UI&quot;, &quot;Helvetica Neue&quot;, Arial, sans-serif, &quot;Apple Color 
Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; 
font-size: 14px;"><div 
dir="auto"><wbr>So&nbsp;<wbr>far&nbsp;<wbr>I'm&nbsp;<wbr>struggling&nbsp;<wbr>with&nbsp;<wbr>uart&nbsp;<wbr>and&nbsp;<wbr>early_printf...<wbr></div><div 
dir="auto"><br></div><div 
dir="auto"><wbr>I'm&nbsp;<wbr>mixing&nbsp;<wbr>this&nbsp;<wbr>activity&nbsp;<wbr>with&nbsp;<wbr>my&nbsp;<wbr>current&nbsp;<wbr>occupation,&nbsp;<wbr>so&nbsp;<wbr>I&nbsp;<wbr>don't&nbsp;<wbr>expect&nbsp;<wbr>rapid&nbsp;<wbr>progress.<wbr></div><div 
dir="auto"><br></div><div 
dir="auto"><wbr>Thank&nbsp;<wbr>you&nbsp;<wbr>for&nbsp;<wbr>clarifications!&nbsp;<wbr>I'll&nbsp;<wbr>try&nbsp;<wbr>to&nbsp;<wbr>do&nbsp;<wbr>my&nbsp;<wbr>best!<wbr></div><div 
dir="auto"><br></div><div dir="auto"><wbr>Stan</div></div></div><div 
dir="auto"><br></div></div><div class="replyHeader" dir="auto">Oskar 
Holmlund wrote:</div><br><br><div><blockquote 
cite="mid:5d65957f4c04a4bec7ae6ef5469b149c@ohdata.se" type="cite" 
style="margin:0 0 0 .8ex;border-left:1px #ccc 
solid;padding-left:1ex"><div>Hi Stanislav,</div><div><br></div><div>Please 
resend your message and CC the arm mailing list. It might be interesting 
for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ 
) otherwise they all think you stopped working on the STM32 
port.</div><div><br></div><div>You should always keep one terminal up n 
running % man 9 style :)</div><div>https://wiki.freebsd.org/Phabricator 
will give you some information.</div><div>Its good if you get to know the 
people active in the ARM area, just keep an eye on the mailinglist and you 
will notice some names. If you have the opportunity to join any of the 
conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even 
more people.</div><div>Join the IRC, for example on efnet #bsdmips is a 
good channel for ARM stuff.</div><div><br></div><div>Start with small 
changes and you will get feedback. From there the experience will grow and 
you will get into it all.</div><div><br></div><div>Correct, the device-tree 
import is from the Linux kernel and there is no prior work for the 
STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD 
either.</div><div>Probably because the STM32MP15 is the first(?) 
application SoC from ST?</div><div><br></div><div><br></div><div>1) hum? Do 
you need that for the reviews? It should be in SRC</div><div>2) Target 
branch is probably main.</div><div>3) It depends, if your custom board is 
opensource and availble around the globe through mouser/farnell/.. I dont 
see any problem. Otherwise pick the board from ST that you used as a 
reference when you developed the custom board.</div><div>For example in my 
day job we have a custom board built around the octavosystems OSD3358 that 
can be found in pocketbeagle/beaglebone black wifi. So the code thats goes 
into the FreeBSD project are all tested on the beaglebone boards. The stuff 
we need for our custom board like the device tree is keept as local patches 
in our inhouse build 
process.</div><div><br></div><div>//Oskar</div><div><br></div><div><div>2023-10-28 
14:25 skrev Stanislav Silnicki:</div></div><br><blockquote 
class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px 
#ccc solid;padding-left:1ex"><div> Hi Oskar!</div><div> &gt; can you point 
me some guidelines to help myself to fit development</div><div> process? 
I'm sure, there is mature dev. culture around FBSD and I'd be</div><div> 
happy to make my contribution coherently from the beginning.</div><div> 
&gt; So far I'm done with setup of my account at reviews (keys, 2FA, 
etc.)</div><div> &gt; As I understand, there is no considerable progress 
with STM32,</div><div> although I have noticed, there are some DTS imported 
into the project.</div><div> &gt; &gt; Indeed, several major 
questions:</div><div> 1. repo url?</div><div> 2. tagret branch for patches 
for stm32 hw?</div><div> 3. is it possible to target custom board from our 
project, or I have</div><div> to ensure support for all dev. boards, 
provided by STM?</div><div> &gt; Thank you,Stan</div><div> &gt; Oskar 
Holmlund wrote:</div><div> &gt;&gt; 2023-10-27 22:33 skrev Stanislav 
Silnicki:</div><br><block<div>quote class="gmail_quote" type="cite" 
style="margin:0 0 0 .8ex;border-left:1px #ccc 
solid;padding-left:1ex"&gt;<div> &gt;&gt;&gt; Hello!</div><br><blockquote 
class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px 
#ccc solid;padding-left:1ex"><br><blockquote class="gmail_quote" 
type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc 
solid;padding-left:1ex"><div> I'm porting onto the subject hardware. So far 
the progress is</div><div> modest,</div><div> while the system boots 
(without console although...)</div><div> One of major issues is hardcoded 
value inside locore-v6.S. Here</div><div> is my</div><div> relevant 
post:</div><div> &gt;&gt; &gt; 
https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438</div><div>; 
[1]</div><div> What is the best way to proceed? Patch, vendor kernel 
build,</div><div> something</div><div> else?</div><div> 
Stan</div><br></blockquote><br><blockquote class="gmail_quote" type="cite" 
style="margin:0 0 0 .8ex;border-left:1px #ccc 
solid;padding-left:1ex"><br></blockquote><div> &gt; 
Links:</div><br></blockquote><div> ------</div><div> &gt;&gt; [1] 
&gt;</div><div> &gt; 
https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438</div><div>; 
&gt;&gt; Hi Stan,</div><div> &gt;&gt; Upload your patch to 
reviews.freebsd.org</div><div> &gt;&gt; Love to see your other patches for 
the 
STM32MP15x.</div><br><div><div>kquote&gt;</div></div><br></block<div></blockquote><div> 
&gt;&gt; //Oskar</div></blockquote></div>
                                  </div></blockquote></div>
                                  </div></blockquote></div>
                                  </div>
               </div></blockquote></div>
                                  </div></blockquote></div>
       
     
   
                   </div></body></html>
------sinikael-?=_1-17003547656200.5932120312415674--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19de1a006e313.760d63ffe37aa>