cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Sat Sep 11, 2021 8:03 am

Gavinmc42 wrote:
Sat Sep 11, 2021 7:36 am
Just remembered Barebox, one plan was to add a FB console screen to it.
viewtopic.php?f=72&t=240622

Wonder what it can do this days on a Pi4?
Never did get around to exploring NOOBS and PINN.
i did recently remember that noobs/pinn is a thing when i was messing with the reboot/shutdown logic

in theory, i could implement a new pinn ui, that boots faster then the stock one

i have also been in contact with the barebox guys on their irc channel, and porting it over might be another fun side-project

User avatar
Gavinmc42
Posts: 6194
Joined: Wed Aug 28, 2013 3:31 am

Re: open firmware and booting custom apps fast

Sat Sep 11, 2021 9:04 am

i have also been in contact with the barebox guys on their irc channel, and porting it over might be another fun side-project
Good, an easy to get running Pi version of that could be useful.
Fast booting display Pi's for single purpose apps will be really handy.
.
One of the RPT guy told me it was crazy to do digital signage in baremetal.
To me is was crazy not to do it, not that I use real baremetal anyway :lol:
It is a big market, room for everyone.

Hmm, not sure why they need fast boot for fixed displays but I have two pedal powered Pi's.
Raspbian boot time is slow, even more stuff in the latest OS.
They were made using old OS/Java code no longer supported.
Just need to figure out overlays to finish rebuilding those old projects from 2015.

Been reading the mmal stuff, overlay support for "sub picture"?
Is that in the Pi firmware?
Mmal is another well documented interface ;)

Battery or solar powered stuff, needs fast boot and low duty cycle.
Power up, read sensors or take pic, power down as fast as possible.
That's part of the IoT market.

One of the reasons I now have a bunch of CM4 is the standby power drain is low. Plus I get two camera ports.
Hmm, that reminds me, get RTC software working on CM4IO board.
It has a wake-up, shut down feature.

Been wanting to do timelapse movies for years.
Should be good with the HQ camera as I can put better lenses on it.
Recently got hooked on Asro-Photography by watching Astrobiscuit YT ch.
Fast booting cameras is one app that does not need Linux.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
procount
Posts: 2574
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: open firmware and booting custom apps fast

Sat Sep 11, 2021 12:12 pm

cleverca22 wrote:
Sat Sep 11, 2021 8:03 am
in theory, i could implement a new pinn ui, that boots faster then the stock one
I never found the bootup time to be a significant problem up until the Pi4. Probably the use of the eeprom bootloader has slowed it down.
PINN uses buildroot/busybox with minimal Linux configuration, so it is quite lean and stripped back. I find the most significant delay is waiting for the network to establish to download the list of OSes. And for that, any newer/quicker firmware needs to be able to boot linux so that standard network and wifi device drivers can be used. The firmware would obviously need to run on all Pi models too.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

User avatar
Gavinmc42
Posts: 6194
Joined: Wed Aug 28, 2013 3:31 am

Re: open firmware and booting custom apps fast

Sat Sep 11, 2021 1:00 pm

Probably the use of the eeprom bootloader has slowed it down.
Boot order need tweaking sometimes.
Variations between the CM4's too, uSD or eMMC etc
I read the commits for eeprom bootloader, mostly for NVMe but I did see some delays removed recently.

Will need to figure out the CM4 boot speeds soon.
Lots of stuff gets done in that Boot eeprom now.
Not sure I want to do an open version of that to boot faster.

A simple camera app on basic CM4 board might not need WiFi, PCIe, Networking and USB3.
512KB eeprom, fit the whole app in that?
First thing I thought of when I found out it was 4Mb.

Yep network connect can take ages.
My baremetal gadgets are mostly non internet networked as SSH/WiFi is not yet available or needed.
For local networking they are ok.
Some apps I need NTP up before I run them, time stamping data logs.
An RTC could replace that need

i use PiCore for SSH networking about 12 seconds booting.
Busybox on that ;) . It is fast enough if I NEED Linux, can be tweak to 8secs so I am told.

Never got Buildroot small enough, learning all those configure options takes ages. It is those dependencies that stump me.
Will need one of Jeff Geerling's Kernel Compile T shirts for that.
Mind you an overclocked Pi400 compiles much faster than a 3B+.
But I want to get an NVMe system for kernel compiling.

Fast booting on CM4 Lite needs investigating now that I have some.
Will the uSD Lite be faster than the eMMC versions.
I got the Lites for code testing as I don't want to wear out the more expensive eMMC versions while developingn

Using the RTC how fast can I boot the CM4 take pictures and shutdown again?
Got lots of things to do in that, Raw image version, Png version, JPEG2000 multispectral.version, multiple cameras.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Sat Sep 11, 2021 5:59 pm

procount wrote:
Sat Sep 11, 2021 12:12 pm
cleverca22 wrote:
Sat Sep 11, 2021 8:03 am
in theory, i could implement a new pinn ui, that boots faster then the stock one
I never found the bootup time to be a significant problem up until the Pi4. Probably the use of the eeprom bootloader has slowed it down.
PINN uses buildroot/busybox with minimal Linux configuration, so it is quite lean and stripped back.
but linux does not even begin to execute, until after start4.elf has done its own bootup logic

if i put pinn directly into start4.elf, i could skip a lot of that time, getting things up sooner

but that initial menu, would be a bit limited, it could only show the OS list, and let you pick one
doing network and disk writes would be a much harder problem
but you can always cheat, and just boot linux on-demand when the user picks one of those options

so the end idea could be to use baremetal start4.elf to present the initial main menu, and give the user X seconds until you run a default
and if they pick something too complicated, just boot linux up, and do what you already can do

but it also opens up a second more cheaty option you couldnt do before
show a fully functioning menu, AND boot linux in parallel!
so the user can see their choices, and in the time it takes for their brain to choose, you finished booting linux!
Gavinmc42 wrote:
Sat Sep 11, 2021 1:00 pm
A simple camera app on basic CM4 board might not need WiFi, PCIe, Networking and USB3.
512KB eeprom, fit the whole app in that?
First thing I thought of when I found out it was 4Mb.
main problem here, is that the existing eeprom app can only execute a start4.elf from the officially documented places, and not from within the eeprom itself
so if you want that kind of feature, you have to also replace the eeprom code
and now you need to bring the dram up, and i have yet to solve that

relying on the closed eeprom, and using an open start4.elf is a valid route, but then your start4.elf must be on a supported location (sd, usb, and so on)
you also have to just accept however long the dram init takes
Gavinmc42 wrote:
Sat Sep 11, 2021 9:04 am
One of the RPT guy told me it was crazy to do digital signage in baremetal.
To me is was crazy not to do it, not that I use real baremetal anyway
It is a big market, room for everyone.
i could very easily throw together a signage example, just load an array of images from disk, and cycle thru them

User avatar
Gavinmc42
Posts: 6194
Joined: Wed Aug 28, 2013 3:31 am

Re: open firmware and booting custom apps fast

Sun Sep 12, 2021 12:07 am

i could very easily throw together a signage example, just load an array of images from disk, and cycle thru them
Did that 3? years ago, did not know all the tricks back then.
8 secs per images was as fast as I could cycle.
Loading the images into ram and swapping them in and out etc.
Other tricks to speed things up did not get looked at.

Tried it on a Pi4, too fast, it needs delays ;)
Easy to do standalone, networking adds issues..
Enable networked image changes and a script for time delays swipe effects etc.
That takes longer to craft than just cycling around images.

Working on an app with background image and sensor data overlays.
Software autoscaling of the image to screen size takes time.
Doing it in HVS would be faster I think.
Embedding a bitmap at screen size into the app code can speed things up a lot.

Overlay with OpenVG work but not for Pi4's.
Still looking for some OpenVG 1.1 Lite example code that might port.
Looks like HermanSW has a solution or two.
Been looking at mmal manuals, "sub picture" is for overlay support.

Forgot I had posted the Pi4 version.
https://github.com/Gavinmc42/Slideshow
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Sun Sep 12, 2021 1:03 am

Code: Select all

] cd root
/root
] cd images
/root/images
] ls
d             4096 .
d             4096 ..
         106475520 x.tar
         106475520 y.tar
          47775762 20191220_105739.tga
           6259518 Pi-Family-Photo-Master-Nov-2016_1500.tga
            962202 Screenshot_2020-07-17_18-05-05.tga
          47775762 camera_capture.tga
           3686418 software_colorbars_image03.tga
] 
ok, step one is done, i have a folder full of images, of random pi related things, and i can see it from the firmware

User avatar
Gavinmc42
Posts: 6194
Joined: Wed Aug 28, 2013 3:31 am

Re: open firmware and booting custom apps fast

Sun Sep 12, 2021 2:07 am

Filesystem seems to work :D
Nearly there, image file reader and render to FB next?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Sun Sep 12, 2021 2:19 am

Code: Select all

name is /root/images/20191220_105739.tga
tga_decode: unknown data type 3
https://en.wikipedia.org/wiki/Truevision_TGA wrote: 2 uncompressed true-color image
3 uncompressed black-and-white (grayscale) image
10 run-length encoded true-color image
LK only supports 2 and 10, but 3 is the default
have to re-make the images with "convert in.jpg out.tga -compress RLE"

Code: Select all

[clever@amd-nixos:~/Pictures/rpi]$ ls -lh x/
total 174M
-rw-r--r-- 1 clever users  45M Sep 11 23:07 20191220_105739.tga
-rw-r--r-- 1 clever users  46M Sep 11 23:07 camera_capture.tga
-rw-r--r-- 1 clever users 3.2M Sep 11 23:08 Pi-Family-Photo-Master-Nov-2016_1500.tga
-rw-r--r-- 1 clever users  75K Sep 11 23:08 Screenshot_2020-07-17_18-05-05.tga
-rw-r--r-- 1 clever users 324K Sep 11 23:08 software_colorbars_image03.tga
will take a few mins to copy the images to the pi, the ethernet is slightly unstable, for unknown reasons

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Sun Sep 12, 2021 3:05 am

*doh*

it helps if you read the file before you decode it!

i was just doing malloc, and then jumping right to decode, but now it works

Code: Select all

NTSC on at 5,356,157 uSec
] slideshow_load
name is /root/images/20191220_105739.tga
decoding
opened an image of 4608 x 3456, reading took 46,764,393 uSec, decoding took 22,225,584 uSec
so, it took 46 sec to read a 45mb file from the uSD card into ram, without any dma acceleration
then it took a full 22 seconds to decode that image

also, i'm going way overkill, i'm feeding it 4608 x 3456 pictures, when the output screen is only 720x480!

now to implement displaying and cycling

edit:
from how its artifacting, i dont think the hardware is capable of doing a /20 reduction in size in realtime
so it cant reduce a 4608x3456 image down to 230x172
i'll need to use smaller images as samples, preferably ones pre-resized to fit the native res

edit 2:
and its 95% working!

Code: Select all

welcome to lk
ST_CLO: 6,412,068
slideshow starting at 7,515,914 uSec since boot
file too big, skipping
file too big, skipping
name is /root/images/Pi-Family-Photo-Master-Nov-2016_1500.tga
starting app hvs_dance
decoding
opened Pi-Family-Photo-Master-Nov-2016_1500.tga of 1500 x 1391, reading took 3,552,349 uSec, decoding took 2,840,010 uSec
no match insert
first image visible at 14,015,478
flip 14030302
image done loading at 14043843
name is /root/images/Screenshot_2020-07-17_18-05-05.tgaflip 14078755

flip 14144519
decoding
flip 14268214
flip 14334118
flip 14400007
flip 14465788
flip 14531564
flip 14647367
flip 14713116
flip 14778862
flip 14844631
opened Screenshot_2020-07-17_18-05-05.tga of 853 x 376, reading took 168,319 uSec, decoding took 646,088 uSec
image done loading at 14912674
name is /root/images/software_colorbars_image03.tgaflip 14948429

flip 15064224
flip 15128177
flip 15193931
flip 15257873
flip 15323633
decodingflip 15446976

flip 15512734
flip 15576678
...
flip 17575913
flip 17689582
opened software_colorbars_image03.tga of 1280 x 960, reading took 532,904 uSec, decoding took 2,246,195 uSec
image done loading at 17730640
all images loaded at 17746041
flip 17761041
flip 18714796
flip 19663512
flip 20615259
flip 21529207
flip 22482899
it took ~6 seconds to netboot, but its faster from an SD card, so you can just subtract most of that from the future numbers
3.5 seconds to load from disk, and 2.8 seconds to decode the first image
~7 seconds from the app starting, to the first image being visible on screen
~1 second to load the 2nd image in a thread, while the first was already visible
~3 seconds to load the 3rd image

due to a bug, its rapidly flipping images during loading, but that could be ironed out if this was intended to be a real product
it then procedes to flip thru the images, at a rate of one second each (despite setting it slower, a 2nd bug)
after the initial loading, all images are held in ram, and it can switch images in a single frame worth of time

https://github.com/librerpi/lk-overlay/ ... lideshow.c
and there is the full source

and thats all, with the cpu running at 216mhz, it could run at twice that clock if i fiddle with more things


edit3:
and those delay bugs are all fixed!
current_time() was returning the time in the wrong unit, which screwed up the entire timing system of LK
but i had never done anything timing sensitive until now, so i just didnt notice!

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Sun Sep 12, 2021 6:55 am

double *doh*

the cpu cache was entirely off

i doubled the clock freq (216->432mhz) and enabled the cache, now the numbers are:

Code: Select all

slideshow starting at 5,765,096 uSec since boot
opened Pi-Family-Photo-Master-Nov-2016_1500.tga of 1500 x 1391, reading took 2,721,544 uSec, decoding took 404,817 uSec
first image visible at 8,918,288
opened Screenshot_2020-07-17_18-05-05.tga of 853 x 376, reading took 79,171 uSec, decoding took 60,306 uSec
opened software_colorbars_image03.tga of 1280 x 960, reading took 306,586 uSec, decoding took 231,078 uSec
all images loaded at 9,623,177
it now takes only ~3 seconds to show the first image, and ~4 seconds to load them all

User avatar
Gavinmc42
Posts: 6194
Joined: Wed Aug 28, 2013 3:31 am

Re: open firmware and booting custom apps fast

Sun Sep 12, 2021 8:55 am

it now takes only ~3 seconds to show the first image, and ~4 seconds to load them all
That's more like it :D
Try it on a Zero at full speed?
Didn't know LK did images, that explains those tga files.

Tweaking from now on might save fractions of seconds.
Hardware JPEG decoding, there is the HelloPi JPEG example.
Never figured out how to display the decoded file.

I think JPEG hardware and HVS to screen res are the only things that might help boot to first image faster, apart from embedding the first image in the kernel.
Embed a full screen bitmap or a tiny JPEG the JPEG and HVS decodes and scales?
I have not explored which is faster as more accurate timing is needed.
Hmm there is a timer that starts on boot, stop it one image is displayed?

After the first image is up then slideshows don't normally do the second instantly.
5 secs minimum between slides for viewers to grok the images?
Might have to googoo what real ones do.

What's next, Audio sound track or videos?
It looks like LK is a viable way to do interesting things.

Turning these little experiments into products is 20-50 times harder and more expensive.
20 years ago it needed about 10 people, years and buckets of money to do this stuff.
Now a $8.94AUD Zero, the right software tools and know how, anyone can do it if shown.

So will this LK app port to the Pico, shave a few dollars off :lol:
HDMI or VGA?
Have not had much luck with baremetal USB OTG on the Zero.
USB GUD displays with Pico?

Camera apps are next for me after I finish these two projects..
Fast booting Possum box cameras are on my to do list.
Tricky as RF comms and solar powered is needed.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Sun Sep 12, 2021 9:20 am

Gavinmc42 wrote:
Sun Sep 12, 2021 8:55 am
Hardware JPEG decoding, there is the HelloPi JPEG example.
i believe that example just talks to the blob over the mailbox, so you have to RE the blob either way
Gavinmc42 wrote:
Sun Sep 12, 2021 8:55 am
Hmm there is a timer that starts on boot, stop it one image is displayed?
there is a counter that counts up at 1mhz (1 uSec per tick), and it starts the instant the reset line is released, when the maskrom starts up
by reading that at any time, you can get the exact uptime of the system, including any time spent before linux had even started

most of my timing measurements, are just checking the count before&after, and reporting the difference
Gavinmc42 wrote:
Sun Sep 12, 2021 8:55 am
I think JPEG hardware and HVS to screen res are the only things that might help boot to first image faster, apart from embedding the first image in the kernel.
another trick you could use, is just fewer bits per pixel
all of my testing has been at full 32bit-per-pixel RGBA8888 images
but the hardware can go as low as 8bpp RGB332 images
with 1/4th the number of bytes, you could fit the same image in less space, even uncompressed

User avatar
Gavinmc42
Posts: 6194
Joined: Wed Aug 28, 2013 3:31 am

Re: open firmware and booting custom apps fast

Sun Sep 12, 2021 11:09 am

but the hardware can go as low as 8bpp RGB332 images
Of course, the obvious, 256 colours.
Plenty enough for Info slides.
Been using 32bit with Alpha till now.

Going to have to think about that some more, not sure if it will be needed.
3 second boot time is probably going to be fast enough for slideshows or AV players.

What will need faster booting?
Non HID uses?
Real-time control systems?
The ARM CPU A type is not the best choice for that.

Do these 4 core Pis still support Jazelle, Java Byte code?
I don't remember anyone running Java Byte code on the 1176 Pi's.
Wonder what that could be used for?
More stuff to learn.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Sun Sep 12, 2021 9:03 pm

Gavinmc42 wrote:
Sun Sep 12, 2021 11:09 am
What will need faster booting?
Non HID uses?
Real-time control systems?
The ARM CPU A type is not the best choice for that.
the VPU can deal with the real-time half of things, and the arm can deal with speed and raw compute

one idea i had but havent tested yet, is to make the arm into a TGA decompression slave
in theory, the VPU can boot up and manage the slideshow
but it can spin up the arm, purely to have a 1ghz quad-core tga decoder, lol

i can also see it being useful for say a thermostat system for example
the VPU can boot in seconds, and give a working gui and manage turning the heat on/off at the setpoint
but linux can boot in the background, and deal with the wifi uplink and cloud style features

User avatar
Gavinmc42
Posts: 6194
Joined: Wed Aug 28, 2013 3:31 am

Re: open firmware and booting custom apps fast

Mon Sep 13, 2021 1:16 am

but linux can boot in the background, and deal with the wifi uplink and cloud style features
Good idea. Linux does have that stuff sorted.

The VPUs are running a ThreadX app.
Replace that with a LK one?
I prefer Open firmware all around.
QEMU for VPU is looking more useful.
I checked years ago the QPU's have no access to GPIO :(

Temp sensors are one of the first I2C sensors I used on Pi's.
Made a controller with a Zero that worked pretty good for a portable PCR.
Very fancy thermostat.
Controlled by config files and two button interface.
Never got around to a GUI for it.
Single purpose PLC type Thermostat.

A Generic version could be a Product.
Probably already is somewhere?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Mon Sep 13, 2021 1:57 am

Gavinmc42 wrote:
Mon Sep 13, 2021 1:16 am
Made a controller with a Zero that worked pretty good for a portable PCR.
Very fancy thermostat.
Controlled by config files and two button interface.
Never got around to a GUI for it.
Single purpose PLC type Thermostat.

A Generic version could be a Product.
Probably already is somewhere?
https://www.youtube.com/watch?v=Zm378x6zJYc
https://www.youtube.com/watch?v=7kJ2o7P8D00

from this channel, i have seen that PCR machines can be pretty expensive, so there is definitely a market for DIY ones and plans for making them more cheaply

for a simple job like that, you could use either a pico or a pi0 without the arm even being turned on

https://shop.pimoroni.com/products/hype ... 9485443155
in theory, i can get a hyperpixel screen working on the pi0, and now you have a gui for the control system, complete with touch screen

User avatar
Gavinmc42
Posts: 6194
Joined: Wed Aug 28, 2013 3:31 am

Re: open firmware and booting custom apps fast

Mon Sep 13, 2021 2:39 am

from this channel, i have seen that PCR machines can be pretty expensive, so there is definitely a market for DIY ones and plans for making them more cheaply
It took me six years but I ended up with a Zero controlled PCR that I am told works better than a $80,000 one ;)
The tech has moved on and a DIY pocket sized version should be even easier now and a Pico will be able to do it.
There is just one more tech advance I am waiting on to make it more universal.
Cheap all in one RGBUV VCSEL lasers.

Don't let that YT guy anywhere near bats.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Mon Sep 20, 2021 3:21 pm

ive now added a device-tree api between the main firmware and the arm bootloader
that is then used to simplify configuring the linux framebuffer, and also pass along boot time metrics
Screenshot_2021-09-20_12-10-01.png
Screenshot_2021-09-20_12-10-01.png (21.66 KiB) Viewed 1076 times
my efi laptop is reporting these numbers in "systemd-analyze plot" and i wanted to get that working on the rpi as well

Code: Select all

[root@nixos:~]# cd /proc/device-tree/timestamps

[root@nixos:/proc/device-tree/timestamps]# dtc -s . -f
<stdout>: ERROR (name_properties): /: "name" property is incorrect ("timestamps" instead of base node name)
Warning: Input tree has errors, output forced
/dts-v1/;

/ {
        3stage2_arch_init = <0x788937b>;
        4stage2_arm_start = <0x78be0da>;
        5arm_platform_init = <0x79e3d2b>;
        6arm_linux_soon = <0x7e3be5c>;
        name = "timestamps";
};
this is reporting the number of uSec that have passed since coming out of reset, for 4 points in the boot process

126 seconds until the lk.elf began running, because i'm currently sending it over the uart with xmodem
216ms for lk.elf to bring the ntsc online, and start the arm core
1.2 seconds for the arm core to fully start up (thats odd, i should investigate that later)
4.5 seconds to load the linux zImage, and get ready to execute it

https://i.imgur.com/nbDaM4p.png
Image

and this is then the full "systemd-analyze plot", but its not yet patched to report the firmware times


edit:
oops, and the arm core was still set to 250mhz!
doubling it to 500mhz did improve the boot times noticably, 47sec->28sec for the main userspace end of the boot process

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Tue Sep 21, 2021 4:43 am

download.png
download.png (10.06 KiB) Viewed 1004 times
and once i figured out some alpha issues, i now have X11 working fully, complete with a login prompt and xeyes/xterm

xfce is building now...

this is what it looked like without fixing the alpha problems:
download (1).png
download (1).png (8.64 KiB) Viewed 1004 times

User avatar
Gavinmc42
Posts: 6194
Joined: Wed Aug 28, 2013 3:31 am

Re: open firmware and booting custom apps fast

Tue Sep 21, 2021 5:44 am

1.2 seconds for the arm core to fully start up
That seems a long time.
Wonder what is going on there.
Longer for 4 core Pi's?

Get rid of all that X11 graphical stuff, that takes forever ;)
Does Wayland boot faster?

Kind of cool you have LK booting Linux.
Boot time dependent on that clock speed?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Tue Sep 21, 2021 6:03 am

Code: Select all

  0.159673 [SDRAM:sdram_init]: (0) SD_CS = 0x794200
  0.242702 [SDRAM:sdram_init]: SDRAM Type: Elpida 1GB LPDDR2 (BC=0x58)
  0.289496 [SDRAM:selftest]: Self test successful!
126.761881 [PLATFORM:platform_early_init]:
127.042734 [ARM:arm_init]: armid 0x364d5241, C0 0x0
127.172948 [ARM:bridgeStart]: starting async bridge now!
128.188854 [PLATFORM:platform_early_init]:
128.345879 [EMMC:init_card]: Card initialization complete: NCard 15423MB SDHC Card
enabled some of the older code, to timestamp every message in seconds since poweron
oh
*facepalm*

Code: Select all

393   logf("starting async bridge now!\n");
394   udelay(1000000);
395   *REG32(ARM_CONTROL1) &= ~ARM_C1_REQSTOP;
i wonder why it has a 1 second delay! lol

edit:

Code: Select all

126.643743 [ARM:arm_init]: armid 0x364d5241, C0 0x0
126.773941 [ARM:bridgeStart]: starting async bridge now!
126.789853 [PLATFORM:platform_early_init]:
126.946605 [EMMC:init_card]: Card initialization complete: NCard 15423MB SDHC Card
the arm core is now running the bootup logic just 0.01 seconds after being enabled, as i would have expected

edit2:
Gavinmc42 wrote:
Tue Sep 21, 2021 5:44 am
Get rid of all that X11 graphical stuff, that takes forever
Does Wayland boot faster?
due to other issues, the DRM api isnt working right now, so i just have a dumb /dev/fb0 exposed to linux
wayland could maybe run, but it wont have any hw accel to make it run well

after i enable the other 3 arm cores (linux is still single-core!), i need to investigate the 2d accel stuff more

but non-accelerated is still a major step forward, its now at a point where you could use it as a basic SBC

User avatar
Gavinmc42
Posts: 6194
Joined: Wed Aug 28, 2013 3:31 am

Re: open firmware and booting custom apps fast

Tue Sep 21, 2021 8:05 am

Arm in 10ms is much better ;)
but non-accelerated is still a major step forward, its now at a point where you could use it as a basic SBC
Pi400 runs at 2GHz, might be fast enough for software rendering FB :lol:

Accelerated 2D seems dead on Pi4, no support, needs something like MonkVG etc for 2D.

Been looking at OpenGLES for animations but all I have is a triangle example.
Learn OpenGLES, not sure how to do that on a Pi4 either.
Since I have plenty of VC4 Pi's will use them to learn baremetal OpenGLES.

How to do that on a Pi4, DRM/DRI?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Tue Sep 21, 2021 5:32 pm

https://github.com/librerpi/lk-overlay/ ... /v3d/v3d.c

this is the source ive been using lately, for the 3d core
but the pi4 changed how some parts of the 3d core work, and i'm currently in the dark on exactly what changed

but the pi4 3d core, isnt even supported by the blob!, so all of the answers are in the source for linux and mesa

cleverca22
Posts: 4732
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Thu Sep 23, 2021 1:40 am

Code: Select all

[0;root@nixos: ~root@nixos:~]# [  440.175167] reboot: Restarting system
done platform early init
  0.162114 [SDRAM:sdram_init]: (0) SD_CS = 0x794200
  0.291937 [SDRAM:selftest]: Self test successful!
press X to stop autoboot and go into xmodem mode...
wait result: -13
 10.358288 [EMMC:restart_controller]: hcfg 0xE, cdiv 0x0, edm 0x8C01, hsts 0x0
 10.703220 [PLATFORM:platform_early_init]: 
MEMORY: 0x0 + 0xa00000: payload ram
MEMORY: 0xa00000 + 0x101: inter arch dtb
 11.121569 [ARM:bridgeStart]: starting async bridge now!
 11.137439 [PLATFORM:platform_early_init]: 
done platform early init
core 0 passing control off to linux!!!
C:0x010000C0-0x015B43E0->0x01095700-0x01649A20
Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[root@nixos:~]# dtc -s /proc/device-tree 2>/dev/null | grep timestamps -A10
        timestamps {
                3stage2_arch_init = <0xa33aca>;
                4stage2_arm_start = <0xa6cd72>;
                5arm_platform_init = <0xa9f198>;
                6arm_linux_soon = <0xef52d8>;
        };
};

[root@nixos:~]# 
switched back to using the SD card for a different test, and decided to grab the logs for the timestamps
0.29 seconds to bring ram up
an optional 10 second delay for xmodem to react
about 0.4 seconds to load lk.elf from the SD card
another 0.4 seconds to get the arm core starting
total of 15.684312 seconds from power being applied to linux gaining control of the arm core, 10 of which are optional

after that, its the standard linux boot time optimizations that everybody already knows, and the chosen arm freq

Return to “Bare metal, Assembly language”