Date: Tue, 31 Oct 2023 23:55:56 +0000 From: Stanislav Silnicki <stanislav.silnicki@mailgate.us> To: "freebsd-arm" <freebsd-arm@freebsd.org> Subject: Re: STM32MP157 Message-ID: <0dab0fc75864.77e1118ea80bb@mailgate.us> References: <4d6bf0126f4fb.c24cc5f2fa47c@mailgate.us> <cade2176971ebe57c4cf952a633e12d5@ohdata.se> <00cab7929791c.8af55c0bd1d5f@mailgate.us> <5d65957f4c04a4bec7ae6ef5469b149c@ohdata.se> <d12e3b1a90216.8e6290090dd15@mailgate.us>
next in thread | previous in thread | raw e-mail | index | archive | help
------sinikael-?=_1-16987965570640.08956020169587231
Content-Type: text/plain; format=flowed
Content-Transfer-Encoding: 7bit
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-16987965570640.08956020169587231
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">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"> // FreeBSD version of environment</font></div><div
dir="auto"><font color="#397b21"> env_set("baudrate",
"115200");</font></div><div dir="auto"><font color="#397b21">
env_set("console", "ttyS0,115200");</font></div><div dir="auto"><font
color="#397b21"> env_set("stderr", "serial");</font></div><div
dir="auto"><font color="#397b21"> env_set("stdin",
"serial");</font></div><div dir="auto"><font color="#397b21">
env_set("stdout", "serial");</font></div><div dir="auto"><font
color="#397b21"> env_set("autostart", "yes");</font></div><div
dir="auto"><font color="#397b21"> env_set("loaderdev", "mmc 1"); //
fbsd's ubldr treats our second mmc at index 1</font></div><div
dir="auto"><font color="#397b21"> env_set("bootcmd", "fatload mmc 2
0xc0000000 ubldr && 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: "Open Sans",
-apple-system, BlinkMacSystemFont, "Segoe UI", "Helvetica
Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe
UI Emoji", "Segoe UI Symbol"; font-size:
14px;">OK, <wbr>I <wbr>got <wbr>the <wbr>idea!<wbr></div><div
dir="auto" style="font-family: "Open Sans", -apple-system,
BlinkMacSystemFont, "Segoe UI", "Helvetica Neue",
Arial, sans-serif, "Apple Color Emoji", "Segoe UI
Emoji", "Segoe UI Symbol"; font-size: 14px;"><br></div><div
dir="auto" style="font-family: "Open Sans", -apple-system,
BlinkMacSystemFont, "Segoe UI", "Helvetica Neue",
Arial, sans-serif, "Apple Color Emoji", "Segoe UI
Emoji", "Segoe UI Symbol"; font-size:
14px;"><wbr>As <wbr>I <wbr>realize, <wbr>there <wbr>is <wbr>a <wbr>minor <wbr>bug <wbr>in <wbr>dtc, <wbr>which <wbr>affects <wbr>compilation <wbr>of <wbr>stm's <wbr>originated <wbr>DTBs. <wbr>I <wbr>think <wbr>it <wbr>is <wbr>best <wbr>to <wbr>make <wbr>a <wbr>PR <wbr>into <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> <wbr>which <wbr>I'm <wbr>discussing <wbr>with <wbr>repo <wbr>owner <wbr>already. <wbr>Please <wbr>tell <wbr>me, <wbr>that <wbr>I <wbr>need <wbr>to <wbr>post <wbr>PR <wbr>into <wbr>FBSD <wbr>source <wbr>tree <wbr>if <wbr>it <wbr>is <wbr>a <wbr>shorter <wbr>way <wbr>for <wbr>my <wbr>fix.<wbr><br></div><div
id="tmjah_g_1299" dir="auto" style="font-family: "Open Sans",
-apple-system, BlinkMacSystemFont, "Segoe UI", "Helvetica
Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe
UI Emoji", "Segoe UI Symbol"; font-size:
14px;"><br></div><div id="tmjah_g_1299" dir="auto" style="font-family:
"Open Sans", -apple-system, BlinkMacSystemFont, "Segoe
UI", "Helvetica Neue", Arial, sans-serif, "Apple Color
Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
font-size:
14px;"><wbr>My <wbr>current <wbr>setup <wbr>is <wbr>based <wbr>upon <wbr>QBASE1 <wbr>from <wbr>Karo-<wbr>Electronics, <wbr>but <wbr>there <wbr>is <wbr>no <wbr>goal <wbr>to <wbr>support/<wbr>debug <wbr>all <wbr>peripherals, <wbr>only <wbr>a <wbr>subset, <wbr>including <wbr>USB, <wbr>I2C, <wbr>SDMMC, <wbr>DSI
(<wbr>and <wbr>GPU, <wbr>if <wbr>lucky).<wbr></div><div
id="tmjah_g_1299" dir="auto" style="font-family: "Open Sans",
-apple-system, BlinkMacSystemFont, "Segoe UI", "Helvetica
Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe
UI Emoji", "Segoe UI Symbol"; 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: "Open Sans",
-apple-system, BlinkMacSystemFont, "Segoe UI", "Helvetica
Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe
UI Emoji", "Segoe UI Symbol"; font-size:
14px;"><br></div><div id="tmjah_g_1299" dir="auto" style="font-family:
"Open Sans", -apple-system, BlinkMacSystemFont, "Segoe
UI", "Helvetica Neue", Arial, sans-serif, "Apple Color
Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
font-size: 14px;"><wbr>The <wbr>vendor
(<wbr>Karo) <wbr>supports <wbr>only <wbr>their <wbr>Yocto <wbr>based <wbr>Linux <wbr>distro. <wbr>I <wbr>spent <wbr>some <wbr>time <wbr>to <wbr>prepare <wbr>TF-<wbr>A
& <wbr>Uboot, <wbr>capable <wbr>with <wbr>booting <wbr>from <wbr>SD <wbr>card
(<wbr>that <wbr>is <wbr>more <wbr>robust <wbr>approach, <wbr>as <wbr>I <wbr>think). <wbr>STM <wbr>does <wbr>not <wbr>promote/<wbr>support <wbr>non-<wbr>secure <wbr>boot <wbr>approach <wbr>with <wbr>SPL, <wbr>they <wbr>insist <wbr>to <wbr>use <wbr>TF-<wbr>A <wbr>or <wbr>OPTEE, <wbr>so <wbr>it <wbr>is <wbr>pretty <wbr>cumbersome <wbr>path, <wbr>I <wbr>had <wbr>to <wbr>pass. <wbr>I <wbr>think, <wbr>it <wbr>will <wbr>be <wbr>easier <wbr>for <wbr>me <wbr>to <wbr>prepare <wbr>some <wbr>sort <wbr>of <wbr>README <wbr>to <wbr>support <wbr>customization <wbr>of <wbr>uboot <wbr>for <wbr>STM's <wbr>port <wbr>and <wbr>dig <wbr>it <wbr>somewhere <wbr>in <wbr>SRC <wbr>rather <wbr>than 
;
;<wbr>try <wbr>to <wbr>post <wbr>PR's <wbr>in <wbr>those <wbr>repos... <wbr>Not <wbr>sure, <wbr>anyway.<wbr></div><div
id="tmjah_g_1299" dir="auto" style="font-family: "Open Sans",
-apple-system, BlinkMacSystemFont, "Segoe UI", "Helvetica
Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe
UI Emoji", "Segoe UI Symbol"; font-size:
14px;"><br></div><div id="tmjah_g_1299" dir="auto" style="font-family:
"Open Sans", -apple-system, BlinkMacSystemFont, "Segoe
UI", "Helvetica Neue", Arial, sans-serif, "Apple Color
Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
font-size: 14px;"><div
dir="auto"><wbr>So <wbr>far <wbr>I'm <wbr>struggling <wbr>with <wbr>uart <wbr>and <wbr>early_printf...<wbr></div><div
dir="auto"><br></div><div
dir="auto"><wbr>I'm <wbr>mixing <wbr>this <wbr>activity <wbr>with <wbr>my <wbr>current <wbr>occupation, <wbr>so <wbr>I <wbr>don't <wbr>expect <wbr>rapid <wbr>progress.<wbr></div><div
dir="auto"><br></div><div
dir="auto"><wbr>Thank <wbr>you <wbr>for <wbr>clarifications! <wbr>I'll <wbr>try <wbr>to <wbr>do <wbr>my <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> > 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>
> So far I'm done with setup of my account at reviews (keys, 2FA,
etc.)</div><div> > 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> > > 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> > Thank you,Stan</div><div> > Oskar
Holmlund wrote:</div><div> >> 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"><div> >>> 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> >> >
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> >
Links:</div><br></blockquote><div> ------</div><div> >> [1]
></div><div> >
https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438</div><div>;
>> Hi Stan,</div><div> >> Upload your patch to
reviews.freebsd.org</div><div> >> Love to see your other patches for
the
STM32MP15x.</div><br><div><div>kquote></div></div><br></block<div></blockquote><div>
>> //Oskar</div></blockquote></div>
</div></blockquote></div>
</div></body></html>
------sinikael-?=_1-16987965570640.08956020169587231--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0dab0fc75864.77e1118ea80bb>