Re: PicoLisp and PilOS

[András Páhi]

> On 2025. May 21., at 20:53, Alexander Burger  wrote:
> 
> Or did I overlook features in U-Boot?
> 
> ☺/ A!ex


No, you did not overlook anything, U-Boot is just firmware.
You can check the features at https://docs.u-boot.org/en/latest/api/index.html

pahihu

Re: PicoLisp and PilOS

[Alexander Burger]

Thanks for all the info! :)

Installing U-Boot as a bootloader, interacting with its Repl, and
booting a system on it is all fine, good and important.

But I'm not talking about that. My concern is how to interact with the
hardware from inside PilOS *after* it booted.


> Em, hm. I thought the whole idea behind using u-boot is to let care
> about device drivers and other low level stuff to u-boot and compiler.

Yes, it *would* be nice if U-Boot would provide an API abstracting the
hardware.

But U-Boot does not provide runtime hardware services (like BIOS INT 13h
for disk or INT 10h for display) to an OS after the kernel has taken
control. Old PilOS depended on that.


> We can use u-boot's API. u-boot has examples folder and I just tried to
> run those examples in qemu.

All I can find is that U-Boot performs low-level hardware initialization
(memory, I/O, storage, etc.), supports a command-line interface for
interacting with the system, and can handle complex boot scenarios.
Good!

But its hardware access features - such as reading/writing storage,
accessing USB devices, or interacting with the console - are available
*only* within the U-Boot environment itself!

So how to code all the necessary system calls in PilOS? E.g. to draw to
the screen, read and write block to/from flash memory (not to talk about
network access which was also not available in old PilOS, as there is no
support in legacy BIOS)?

Or did I overlook features in U-Boot?

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[mayor84]

Em, hm. I thought the whole idea behind using u-boot is to let care about
device drivers and other low level stuff to u-boot and compiler.
We can use u-boot's API. u-boot has examples folder and I just tried to run
those examples in qemu. Below is my notes. The workflow for PRI, OrangePi
or your phone should be very similar.
I would assume that to port something like miniPicolisp.tgz is the matter
of configuring correct LDFLAGS and CPPFLAGS. But I'm not sufficiently
familiar with u-boot, picolisp and other stuff to make it as easy as it
sounds.

If anything, right now I'm more concerned about my rent and perspective to
lose it, if I don't pay. Such cool projects like picolisp running in u-boot
environment, as of right now is very low on my ToDo list. But if somebody
wants to pick it up from here, I attach my notes about it. Have fun!


https://picolisp.com/wiki/?embedded
https://stackoverflow.com/questions/20190116/serial-pty-in-qemu-how-to-open
https://serverfault.com/questions/1066243/what-is-the-use-case-of-qemu-chardev-pty
https://krinkinmu.github.io/2023/08/12/getting-started-with-u-boot.html
https://www.bidouilliste.com/blog/2015/11/27/Porting-FreeBSD-to-a-new-ARM-Board-Part-1/
https://forums.freebsd.org/threads/compiling-out-of-tree-u-boot.89366/
https://tomscii.sig7.se/2022/03/Patches-for-OpenBSD-on-the-PinebookPro
https://flak.tedunangst.com/post/OpenBSD-on-BeagleBone-Black
https://github.com/elewarr/openbsd-ports-u-boot
https://forum.banana-pi.org/t/bpi-r3-how-i-was-able-to-boot-openbsd-7-5-and-failed/18770
https://github.com/ndhwyd/roc-rk3399-pc_openbsd
https://briancallahan.net/blog/20231119.html


doas pkg_add -r -U picocom qemu u-boot-aarch64 aarch64-none-elf-binutils
aarch64-none-elf-gcc py3-pip py3-pipx autoconf--%2.72 gsed gcc--%8 bison

git clone --depth 1 https://source.denx.de/u-boot/u-boot.git u-boot-github1
zip -r u-boot-github1.zip u-boot-github1/
cd u-boot-github1
gmake help

/usr/bin/env MAKE=gmake PYTHON="/usr/local/bin/python3.12"
PKG_CONFIG=pkg-config

lap1$ gmake SED=gsed HOSTCC=egcc CROSS_COMPILE=aarch64-none-elf- YACC=bison
menuconfig

 Compile API examples
 CONFIG_EXAMPLES:
  U-Boot provides an API for standalone applications. Examples are provided
in directory examples.

lap1$ grep -ir '*defconfig'
board/cortina/presidio-asic/MAINTAINERS:F:
configs/cortina_presidio-asic*defconfig
board/raspberrypi/rpi/MAINTAINERS:F:configs/rpi_*defconfig

export CROSS_COMPILE=aarch64-none-elf-
gmake SED=gsed HOSTCC=egcc CROSS_COMPILE=aarch64-none-elf- YACC=bison
orangepi_2_defconfig
gmake SED=gsed HOSTCC=egcc CROSS_COMPILE=aarch64-none-elf- YACC=bison


export CROSS_COMPILE=aarch64-none-elf-
gmake SED=gsed HOSTCC=egcc CROSS_COMPILE=aarch64-none-elf- YACC=bison
rpi_4_acpi_defconfig
gmake

/bin/sh: iasl: not found
gmake[1]: *** [scripts/Makefile.lib:540:
board/raspberrypi/rpi/dsdt_generated.c] Error 127
gmake: *** [Makefile:1919: board/raspberrypi/rpi] Error 2

///make qemu_aarch64_virt_defconfig
///make menuconfig

ls configs/qemu_arm64_defconfig
export CROSS_COMPILE=aarch64-none-elf-
gmake SED=gsed HOSTCC=egcc CROSS_COMPILE=aarch64-none-elf- YACC=bison
qemu_arm64_defconfig
# make sure to select General setup -> Enable U-Boot API -> API -> Compile
API examples!
gmake SED=gsed HOSTCC=egcc CROSS_COMPILE=aarch64-none-elf- YACC=bison
menuconfig
gmake SED=gsed HOSTCC=egcc CROSS_COMPILE=aarch64-none-elf- YACC=bison

lap1$ file u-boot.bin
u-boot.bin: PCX ver. 2.5 image data
lap1$ strings u-boot.bin | grep qemu
board=qemu-arm
board_name=qemu-arm
qemu,fw-cfg-mmio

lap1$ cat examples/api/demo.c
..
int main(int argc, char *const argv[])

{

printf("This demo were compiled in OpenBSD environment. Hopefully,
one beautiful day, I'll port miniPicolisp the similar way");
..


qemu-system-aarch64 -machine virt,virtualization=on,secure=off -cpu max
-bios u-boot.bin -nographic
lap1$ doas qemu-system-aarch64 -machine virt,virtualization=on,secure=off
-cpu max -bios u-boot.bin -nographic -serial pty
Another pane in tmux:
doas picocom /dev/ttyp5
poweroff

mkdir rootfs
lap1$ cp ./examples/standalone/hello_world* rootfs/
lap1$ cp ./examples/api/demo* rootfs/
lap1$ cd rootfs
lap1$ llvm-objcopy -O binary demo.o demo1.bin


lap1$ llvm-objcopy -O binary demo demo2.bin
lap1$ cd ..
lap1$ strings rootfs/hello_world | grep -i 'pico'


This hello world standalone example is compiled in OpenBSD environment.
Hopefully, one day, I'll port miniPicolisp.tgz to run in u-boot similar way!



qemu-system-aarch64 -machine virt,virtualization=on,secure=off -cpu max
-bios u-boot.bin -nographic -drive
file=fat:rw:./rootfs,format=raw,media=disk

=> virtio info
Device 0: 1af4 VirtIO Block Device
Type: Hard Disk
Capacity: 504.0 MB = 0.4 GB (1032192 x 512)

=> virtio part 0

Partition Map for virtio device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 63  1032129 be1afdfa-01 06 Boot

=> fatls virtio 0:1
72584   hello_world
  

Re: PicoLisp and PilOS

[Alexander Burger]

On Wed, May 21, 2025 at 12:56:10AM +0500, mayor84 wrote:
> Not sure what driver are you talking about. I was thinking something like
> this

Oh, sorry. When I wrote:

> > access them serially, don't have the toolchains, and don't dare to write
> > necessary device drivers even with the hardware documentation :(

I meant that the serial access to the device is not the main problem. To
get PilOS up and running, you need drivers to write to the screen,
read/write flash memory, access networking hardware and sensors like
touch screen, timers etc.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[mayor84]

Oh. Hi. Just saw your email.

Not sure what driver are you talking about. I was thinking something like
this

https://www.amazon.com/RS232-3-5mm-Serial-Adapter-USB-RS232-AJ/dp/B08CQYJSFC

FTDI drivers are there for any platform. Windows, linux. On openbsd I'm
using picocom,

picocom /dev/ttyU0

The biggest quirk with it is to guess the correct connection parameters.
They're limited like with old phone-line modems. It almost feels so
obvious, that anybody should know how to use it. Just read man for picocom.
It even knows how to do x-modem, so you can send files to/from the device
right through the serial connection. ;)


On Sun, May 18, 2025, 14:14 Alexander Burger 
wrote:

> Thanks mayor84!
>
> > Made a little research. Looks like Nexus7 does have jtag and uart. May be
> > Nexus9 is the same.
> > ...
>
> Lots of promising details indeed :)
>
> It seems, however, that I still lack most of the necessary
> infrastructure to tackle this. I did install LineageOS about ten years
> ago on those devices via the HBOOT loader without problems, but I cannot
> access them serially, don't have the toolchains, and don't dare to write
> necessary device drivers even with the hardware documentation :(
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: PicoLisp and PilOS

[Alexander Burger]

Thanks mayor84!

> Made a little research. Looks like Nexus7 does have jtag and uart. May be
> Nexus9 is the same.
> ...

Lots of promising details indeed :)

It seems, however, that I still lack most of the necessary
infrastructure to tackle this. I did install LineageOS about ten years
ago on those devices via the HBOOT loader without problems, but I cannot
access them serially, don't have the toolchains, and don't dare to write
necessary device drivers even with the hardware documentation :(

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[mayor84]

Made a little research. Looks like Nexus7 does have jtag and uart. May be
Nexus9 is the same.
https://github.com/tofurky/tegra30_debrick/blob/master/image/n7_uart_schematic.jpg

Also, here the dude actually wrote an OS for Nexus9. On assembler of couse.
64-bit ARM OS/Kernel/Systems Development Demo on a Nexus 9
https://github.com/andreiw/nexus9_demo

Also, I'm just looking at htc's HBOOT, and it suspiciusly looks like
u-boot. And the guy is using a UART headphone jack adapter to a computer.
And he's able to boot his custom code successfully. Another bread crum.

And it has an actual vendor's documentation!
https://developer.nvidia.com/embedded/tegra-k1-reference

And the u-boot has an example for another tegra phone. It might have some
similarities with Nexus 9
https://github.com/u-boot/u-boot/blob/master/doc/board/htc/endeavoru.rst

I just don't have such device myself. So I'll stop researching that. But I
promise to test out pil21-u-boot-or-whatever on OrangePiZero which I have.
I might also have RPI but I have to find it.

On Fri, May 16, 2025, 11:13 mayor84  wrote:

> Pure guessing here. External ram and MMU are board specific. Probably eMMC
> needs special care in configs. And serial port which suppose to be
> integrated in soc. It's probably the bare minimum for any OS.
>
> Another question how to upload that new firmware to your dev. It could be
> bootlocked, etc. I didn't have much exp and success with phones. Sbc like
> OrangePi and Raspberry Pi are much more straight forward.
>
> Also, I don't know if nexus phones have special connectors to communicate
> with serial port or jtag.
>
> On Fri, May 16, 2025, 10:20 Alexander Burger 
> wrote:
>
>> On Thu, May 15, 2025 at 09:25:59PM +0500, mayor84 wrote:
>> > I might be wrong, but is it u-boot already configured for nvidia tegra
>> k1
>> > soc?
>> >
>> > System chip NVIDIA Tegra K1 (28 nm)
>> > Processor Dual-core, 2300 MHz, Denver
>> > GPU Kepler
>> > RAM 2GB (DDR3)
>> > Internal storage 32GB
>> >
>> > https://www.phonearena.com/phones/Google-Nexus-9_id8926
>>
>> Yes, that's the right one.
>>
>>
>> > https://github.com/OE4T/u-boot-tegra
>>
>> Hmm, OK, this may cover the CPU, but what support for the rest of the
>> hardware is needed to boot PilOS?
>>
>> ☺/ A!ex
>>
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>

Re: PicoLisp and PilOS

[mayor84]

Pure guessing here. External ram and MMU are board specific. Probably eMMC
needs special care in configs. And serial port which suppose to be
integrated in soc. It's probably the bare minimum for any OS.

Another question how to upload that new firmware to your dev. It could be
bootlocked, etc. I didn't have much exp and success with phones. Sbc like
OrangePi and Raspberry Pi are much more straight forward.

Also, I don't know if nexus phones have special connectors to communicate
with serial port or jtag.

On Fri, May 16, 2025, 10:20 Alexander Burger 
wrote:

> On Thu, May 15, 2025 at 09:25:59PM +0500, mayor84 wrote:
> > I might be wrong, but is it u-boot already configured for nvidia tegra k1
> > soc?
> >
> > System chip NVIDIA Tegra K1 (28 nm)
> > Processor Dual-core, 2300 MHz, Denver
> > GPU Kepler
> > RAM 2GB (DDR3)
> > Internal storage 32GB
> >
> > https://www.phonearena.com/phones/Google-Nexus-9_id8926
>
> Yes, that's the right one.
>
>
> > https://github.com/OE4T/u-boot-tegra
>
> Hmm, OK, this may cover the CPU, but what support for the rest of the
> hardware is needed to boot PilOS?
>
> ☺/ A!ex
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: PicoLisp and PilOS

[Alexander Burger]

On Thu, May 15, 2025 at 09:25:59PM +0500, mayor84 wrote:
> I might be wrong, but is it u-boot already configured for nvidia tegra k1
> soc?
> 
> System chip NVIDIA Tegra K1 (28 nm)
> Processor Dual-core, 2300 MHz, Denver
> GPU Kepler
> RAM 2GB (DDR3)
> Internal storage 32GB
> 
> https://www.phonearena.com/phones/Google-Nexus-9_id8926

Yes, that's the right one.


> https://github.com/OE4T/u-boot-tegra

Hmm, OK, this may cover the CPU, but what support for the rest of the
hardware is needed to boot PilOS?

☺/ A!ex


-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[mayor84]

I'm still not sure if it correct match. But at least we can ask the
maintainer. Or even port it oursalves. But it would be way beyond my
competence.

https://github.com/OE4T/u-boot-tegra/blob/patches-v2022.01/board/nvidia/jetson-tk1/MAINTAINERS

On Fri, May 16, 2025, 02:29 Páhi András  wrote:

> Great! I suppose this is the device that Alex mentioned.
>
> The GitHub repo modified last time in 2022... no TCP stack, just UDP.
>
> pahihu
> On 2025. 05. 15. 18:25, mayor84 wrote:
>
> I might be wrong, but is it u-boot already configured for nvidia tegra k1
> soc?
>
> System chip NVIDIA Tegra K1 (28 nm)
> Processor Dual-core, 2300 MHz, Denver
> GPU Kepler
> RAM 2GB (DDR3)
> Internal storage 32GB
>
> https://www.phonearena.com/phones/Google-Nexus-9_id8926
> https://github.com/OE4T/u-boot-tegra
>
> On Thu, May 15, 2025, 21:17 mayor84  wrote:
>
>> I just googled it. Here's getting started, I think I followed this one
>> when played with it, some time ago.
>>
>> Also, there was examples of so-called standalone apps which you can just
>> upload to your dev, without updating u-boot itself.
>>
>> And I vaguely remember that it could generate u-boot.elf for host machine
>> and run it in userspace for testing purposes. But right now I can't google
>> anything useful about it. So qemu is the best option to start, indeed.
>>
>> https://krinkinmu.github.io/2023/08/12/getting-started-with-u-boot.html
>>
>>
>> https://github.com/u-boot/u-boot/blob/master/examples/standalone/hello_world.c
>>
>> On Thu, May 15, 2025, 20:07 András Páhi  wrote:
>>
>>> Nope. I’ve searched the web for the Nexus series tablets and U-Boot
>>> images, but all I’ve found just found a similar question on a FreeBSD
>>> forum.
>>>
>>> pahihu
>>>
>>> > On 2025. May 15., at 16:16, Alexander Burger 
>>> wrote:
>>> >
>>> > On Thu, May 15, 2025 at 03:42:42PM +0200, András Páhi wrote:
>>> >> The easy way:
>>> >> Check for up-to-date U-Boot images with TCP support for the Nexus 9,
>>> then update the U-Boot firmware.
>>> >> You can compile and package apps for U-Boot to execute from Flash,
>>> but beware the load address is
>>> >> system/firmware specific.
>>> >>
>>> >> Then if you provide a script for U-Boot to execute on power-up, it
>>> can automatically execute your app.
>>> >
>>> > Do you have any links to such images and documentation?
>>> >
>>> > ☺/ A!ex
>>> >
>>> > --
>>> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>>
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>>>
>>

Re: PicoLisp and PilOS

[Páhi András]

Great! I suppose this is the device that Alex mentioned.

The GitHub repo modified last time in 2022... no TCP stack, just UDP.

pahihu

On 2025. 05. 15. 18:25, mayor84 wrote:
I might be wrong, but is it u-boot already configured for nvidia tegra 
k1 soc?


System chip NVIDIA Tegra K1 (28 nm)
Processor Dual-core, 2300 MHz, Denver
GPU Kepler
RAM 2GB (DDR3)
Internal storage 32GB

https://www.phonearena.com/phones/Google-Nexus-9_id8926
https://github.com/OE4T/u-boot-tegra

On Thu, May 15, 2025, 21:17 mayor84  wrote:

I just googled it. Here's getting started, I think I followed this
one when played with it, some time ago.

Also, there was examples of so-called standalone apps which you
can just upload to your dev, without updating u-boot itself.

And I vaguely remember that it could generate u-boot.elf for host
machine and run it in userspace for testing purposes. But right
now I can't google anything useful about it. So qemu is the best
option to start, indeed.

https://krinkinmu.github.io/2023/08/12/getting-started-with-u-boot.html


https://github.com/u-boot/u-boot/blob/master/examples/standalone/hello_world.c

On Thu, May 15, 2025, 20:07 András Páhi 
wrote:

Nope. I’ve searched the web for the Nexus series tablets and
U-Boot
images, but all I’ve found just found a similar question on a
FreeBSD forum.

pahihu

> On 2025. May 15., at 16:16, Alexander Burger
 wrote:
>
> On Thu, May 15, 2025 at 03:42:42PM +0200, András Páhi wrote:
>> The easy way:
>> Check for up-to-date U-Boot images with TCP support for the
Nexus 9, then update the U-Boot firmware.
>> You can compile and package apps for U-Boot to execute from
Flash, but beware the load address is
>> system/firmware specific.
>>
>> Then if you provide a script for U-Boot to execute on
power-up, it can automatically execute your app.
>
> Do you have any links to such images and documentation?
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe

Re: PicoLisp and PilOS

[mayor84]

I might be wrong, but is it u-boot already configured for nvidia tegra k1
soc?

System chip NVIDIA Tegra K1 (28 nm)
Processor Dual-core, 2300 MHz, Denver
GPU Kepler
RAM 2GB (DDR3)
Internal storage 32GB

https://www.phonearena.com/phones/Google-Nexus-9_id8926
https://github.com/OE4T/u-boot-tegra

On Thu, May 15, 2025, 21:17 mayor84  wrote:

> I just googled it. Here's getting started, I think I followed this one
> when played with it, some time ago.
>
> Also, there was examples of so-called standalone apps which you can just
> upload to your dev, without updating u-boot itself.
>
> And I vaguely remember that it could generate u-boot.elf for host machine
> and run it in userspace for testing purposes. But right now I can't google
> anything useful about it. So qemu is the best option to start, indeed.
>
> https://krinkinmu.github.io/2023/08/12/getting-started-with-u-boot.html
>
>
> https://github.com/u-boot/u-boot/blob/master/examples/standalone/hello_world.c
>
> On Thu, May 15, 2025, 20:07 András Páhi  wrote:
>
>> Nope. I’ve searched the web for the Nexus series tablets and U-Boot
>> images, but all I’ve found just found a similar question on a FreeBSD
>> forum.
>>
>> pahihu
>>
>> > On 2025. May 15., at 16:16, Alexander Burger 
>> wrote:
>> >
>> > On Thu, May 15, 2025 at 03:42:42PM +0200, András Páhi wrote:
>> >> The easy way:
>> >> Check for up-to-date U-Boot images with TCP support for the Nexus 9,
>> then update the U-Boot firmware.
>> >> You can compile and package apps for U-Boot to execute from Flash, but
>> beware the load address is
>> >> system/firmware specific.
>> >>
>> >> Then if you provide a script for U-Boot to execute on power-up, it can
>> automatically execute your app.
>> >
>> > Do you have any links to such images and documentation?
>> >
>> > ☺/ A!ex
>> >
>> > --
>> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>>
>

Re: PicoLisp and PilOS

[mayor84]

I just googled it. Here's getting started, I think I followed this one when
played with it, some time ago.

Also, there was examples of so-called standalone apps which you can just
upload to your dev, without updating u-boot itself.

And I vaguely remember that it could generate u-boot.elf for host machine
and run it in userspace for testing purposes. But right now I can't google
anything useful about it. So qemu is the best option to start, indeed.

https://krinkinmu.github.io/2023/08/12/getting-started-with-u-boot.html

https://github.com/u-boot/u-boot/blob/master/examples/standalone/hello_world.c

On Thu, May 15, 2025, 20:07 András Páhi  wrote:

> Nope. I’ve searched the web for the Nexus series tablets and U-Boot
> images, but all I’ve found just found a similar question on a FreeBSD
> forum.
>
> pahihu
>
> > On 2025. May 15., at 16:16, Alexander Burger 
> wrote:
> >
> > On Thu, May 15, 2025 at 03:42:42PM +0200, András Páhi wrote:
> >> The easy way:
> >> Check for up-to-date U-Boot images with TCP support for the Nexus 9,
> then update the U-Boot firmware.
> >> You can compile and package apps for U-Boot to execute from Flash, but
> beware the load address is
> >> system/firmware specific.
> >>
> >> Then if you provide a script for U-Boot to execute on power-up, it can
> automatically execute your app.
> >
> > Do you have any links to such images and documentation?
> >
> > ☺/ A!ex
> >
> > --
> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

Re: PicoLisp and PilOS

[András Páhi]

Nope. I’ve searched the web for the Nexus series tablets and U-Boot
images, but all I’ve found just found a similar question on a FreeBSD forum.

pahihu

> On 2025. May 15., at 16:16, Alexander Burger  wrote:
> 
> On Thu, May 15, 2025 at 03:42:42PM +0200, András Páhi wrote:
>> The easy way:
>> Check for up-to-date U-Boot images with TCP support for the Nexus 9, then 
>> update the U-Boot firmware.
>> You can compile and package apps for U-Boot to execute from Flash, but 
>> beware the load address is
>> system/firmware specific.
>> 
>> Then if you provide a script for U-Boot to execute on power-up, it can 
>> automatically execute your app.
> 
> Do you have any links to such images and documentation?
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[Alexander Burger]

On Thu, May 15, 2025 at 03:42:42PM +0200, András Páhi wrote:
> The easy way:
> Check for up-to-date U-Boot images with TCP support for the Nexus 9, then 
> update the U-Boot firmware.
> You can compile and package apps for U-Boot to execute from Flash, but beware 
> the load address is
> system/firmware specific.
> 
> Then if you provide a script for U-Boot to execute on power-up, it can 
> automatically execute your app.

Do you have any links to such images and documentation?

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[András Páhi]

The easy way:
Check for up-to-date U-Boot images with TCP support for the Nexus 9, then 
update the U-Boot firmware.
You can compile and package apps for U-Boot to execute from Flash, but beware 
the load address is
system/firmware specific.

Then if you provide a script for U-Boot to execute on power-up, it can 
automatically execute your app.

The hard way:
You compile the U-Boot firmware yourself configured for the SoC on the board.
Most vendors package their HW drivers as binary blobs and protect them with 
NDAs.

The proposed way:
Select a virtual ARM dev-board from QEMU that has the same architecture as your 
target SoC.
Get U-Boot run on that emulated system and port PilOS. You can iterate faster, 
because no need
to re-flash the thing. It worked for me at last.

pahihu

> On 2025. May 15., at 14:52, Alexander Burger  wrote:
> 
> On Thu, May 15, 2025 at 08:56:38AM +0200, András Páhi wrote:
>> I just had a hands-on experience with ARM SoC embedded work, 
>> bricking devboards several times, fighting with HW drivers and
>> staring serial line bitstreams… or waveforms on the scope.
>> This land is for immortals😅
> 
> I still have two ten years old Nexus 9 tablets.
> 
> Is it possible to get them running under U-Boot?
> If so, I would investigate porting PilOS.
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[Alexander Burger]

On Thu, May 15, 2025 at 08:56:38AM +0200, András Páhi wrote:
> I just had a hands-on experience with ARM SoC embedded work, 
> bricking devboards several times, fighting with HW drivers and
> staring serial line bitstreams… or waveforms on the scope.
> This land is for immortals😅

I still have two ten years old Nexus 9 tablets.

Is it possible to get them running under U-Boot?
If so, I would investigate porting PilOS.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[András Páhi]

Yes. But TFTP and NFS support is through UDP.
Since 2022 U-Boot has TCP/HTTP support in the network stack.

I just had a hands-on experience with ARM SoC embedded work, 
bricking devboards several times, fighting with HW drivers and
staring serial line bitstreams… or waveforms on the scope.
This land is for immortals😅

pahihu

> On 2025. May 15., at 8:29, mayor84  wrote:
> 
> U-boot by the way already knows how to handle storage and network. Otherwise 
> it wouldn't be able to boot over network(tftp,etc). It feels almost dos-like. 
> Totally makes sense to use it for something embedded. But for my mere mortal 
> stuff I prefer normal OS of course.
> 
> On Thu, May 15, 2025, 11:01 Alexander Burger  > wrote:
>> On Wed, May 14, 2025 at 05:21:47PM +0200, Lonnie wrote:
>> > This is a good idea and I will look into it more also.
>> 
>> U-Boot looks indeed interesting. At least it simplifies the boot
>> process. But probably it won't help with the bigger problems, like
>> device drivers for network etc.
>> 
>> Compared to that, porting PilOS to pil21 would be relatively easy.
>> 
>> ☺/ A!ex
>> 
>> -- 
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de 
>> ?subject=Unsubscribe

Re: PicoLisp and PilOS

[Alexander Burger]

On Thu, May 15, 2025 at 11:29:00AM +0500, mayor84 wrote:
> U-boot by the way already knows how to handle storage and network.
> Otherwise it wouldn't be able to boot over network(tftp,etc). It feels
> almost dos-like.

That's nice indeed! I must confess this was the first time I
heard about it.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[mayor84]

U-boot by the way already knows how to handle storage and network.
Otherwise it wouldn't be able to boot over network(tftp,etc). It feels
almost dos-like. Totally makes sense to use it for something embedded. But
for my mere mortal stuff I prefer normal OS of course.

On Thu, May 15, 2025, 11:01 Alexander Burger 
wrote:

> On Wed, May 14, 2025 at 05:21:47PM +0200, Lonnie wrote:
> > This is a good idea and I will look into it more also.
>
> U-Boot looks indeed interesting. At least it simplifies the boot
> process. But probably it won't help with the bigger problems, like
> device drivers for network etc.
>
> Compared to that, porting PilOS to pil21 would be relatively easy.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: PicoLisp and PilOS

[Alexander Burger]

On Wed, May 14, 2025 at 05:21:47PM +0200, Lonnie wrote:
> This is a good idea and I will look into it more also.

U-Boot looks indeed interesting. At least it simplifies the boot
process. But probably it won't help with the bigger problems, like
device drivers for network etc.

Compared to that, porting PilOS to pil21 would be relatively easy.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[Lonnie]

Hello,
> 
> Not that I know much about OS building. I just wanted to note that to port
> pil21 to u-boot would be much easier than fight bios calls. For example,
> strings app in u-boot terminal is written in normal c. And you gonna get
> all the bells and whistles of u-boot, like support for uefi, etc out of the
> box.
> https://github.com/u-boot/u-boot/blob/master/cmd/strings.c
> 

This is a good idea and I will look into it more also.

Thanks,


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[Lonnie]

Hi All,

> Porting to Pil21 would be nice, giving all new features like improved
> coroutines, namespaces and the Vip editor. But this is really difficult.
> PilOS is written in PilASM while Pil21 is written in Lisp, which in turn
> compiles to LLVM.
> 
> An even bigger problem might be that modern BIOSes don't support those
> legacy hardware abstractions any more. They boot the OS and expect it to
> come with all necessary drivers.
> 

Yea, I'm still researching this as well as getting a better feel for PicoLisp 
as well but making progress.

> 
> Is it really necessary that it directly runs on bare metal? Why not boot
> a simple Linux first?
> 

Not that it is required at this stage and will probably just be running on 
Linux first, but as a later goal and also for the enjoyment of not having to 
depend upon an OS, I would like to run it on bare metal and independent. Kinds 
of reminds me of hardware based Lisp machines.

I figure that if you are going to make something like an AGI which might be 
graph based symbolic AI that you might as well try to make it have complete 
control of the hardware. Why not and see what is possilbe, perhaps, is my 
thought.

> 
> Cool! Please keep us informed!
> 
Definitely will keep the team updated :)


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[mayor84]

Hi, Lonnie!

Not that I know much about OS building. I just wanted to note that to port
pil21 to u-boot would be much easier than fight bios calls. For example,
strings app in u-boot terminal is written in normal c. And you gonna get
all the bells and whistles of u-boot, like support for uefi, etc out of the
box.
https://github.com/u-boot/u-boot/blob/master/cmd/strings.c


On Wed, May 14, 2025, 17:37 Alexander Burger 
wrote:

> Hi Lonnie,
>
> > Will have to explore much more, but ultimately would like to have an
> > UEFI version that will boot with the latest pil21 release
>
> Porting to Pil21 would be nice, giving all new features like improved
> coroutines, namespaces and the Vip editor. But this is really difficult.
> PilOS is written in PilASM while Pil21 is written in Lisp, which in turn
> compiles to LLVM.
>
> An even bigger problem might be that modern BIOSes don't support those
> legacy hardware abstractions any more. They boot the OS and expect it to
> come with all necessary drivers.
>
>
> > if my project gets that far in that it is an AI and ML bare metal
> > project that will use specialized graph knowledge database (built on
> > PicoLisp
>
> Is it really necessary that it directly runs on bare metal? Why not boot
> a simple Linux first?
>
>
> > I will keep studying up on PicoLisp towards these goals.
>
> Cool! Please keep us informed!
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: PicoLisp and PilOS

[Alexander Burger]

Hi Lonnie,

> Will have to explore much more, but ultimately would like to have an
> UEFI version that will boot with the latest pil21 release

Porting to Pil21 would be nice, giving all new features like improved
coroutines, namespaces and the Vip editor. But this is really difficult.
PilOS is written in PilASM while Pil21 is written in Lisp, which in turn
compiles to LLVM.

An even bigger problem might be that modern BIOSes don't support those
legacy hardware abstractions any more. They boot the OS and expect it to
come with all necessary drivers.


> if my project gets that far in that it is an AI and ML bare metal
> project that will use specialized graph knowledge database (built on
> PicoLisp

Is it really necessary that it directly runs on bare metal? Why not boot
a simple Linux first?


> I will keep studying up on PicoLisp towards these goals.

Cool! Please keep us informed!

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[Lonnie Cumberland]

Hi Alex,

Yea, I was afraid that the PilOS was a bit dated but was encouraged when 
I saw that it would boot, in legacy BIOS mode, on some hardware that I 
have used to test.  Will have to explore much more, but ultimately would 
like to have an UEFI version that will boot with the latest pil21 
release if my project gets that far in that it is an AI and ML bare 
metal project that will use specialized graph knowledge database (built 
on PicoLisp which I am really starting to enjoy BTW). I have enjoyed 
Lisp going back to my college days but really did not use it a lot since 
that time however, now I really want to get back into the Lisp world and 
for my purposes I think that PicoLisp could be exactly what I have been 
seeking.


I'll have to investigate what it might take to create a new modern PilOS 
based on the latest Pil21 as well as to explore the ideas of how to 
implement a viable graph database in it also.


There are a few other Lisp on hardware projects that I have come across, 
but most are still in a very early state and would not easily boot up 
even in legacy BIOS mode not to mention that I actually like the 
features of PicoLisp that I have been reading on lately as well.


Thanks again and I will keep studying up on PicoLisp towards these goals.

Best
Lonnie

On 5/14/2025 1:30 AM, Alexander Burger wrote:

Hi Lonnie,


(https://picolisp.com/wiki/?PilOS) which I was able to put on a USB and
boot on some hardware just to test out a little.

I am wondering if there are any documentation on the available commands
for PilOS (and running some demos) so that I can explore more?

I'm afraid there is only the above article. PilOS was not continued, and
also is rather outdated because it is built on the now obsolete pil64
(as opposed to the current pil21).

The problem with PilOS is that it does not implement any device drivers,
but uses BIOS calls, which interface only to a few things like display,
keyboard, disk etc, and that most modern hardware does not even support
the standard BIOS calls.

☺/ A!ex

Re: PicoLisp and PilOS

[Alexander Burger]

Hi Lonnie,

> (https://picolisp.com/wiki/?PilOS) which I was able to put on a USB and
> boot on some hardware just to test out a little.
>
> I am wondering if there are any documentation on the available commands
> for PilOS (and running some demos) so that I can explore more?

I'm afraid there is only the above article. PilOS was not continued, and
also is rather outdated because it is built on the now obsolete pil64
(as opposed to the current pil21).

The problem with PilOS is that it does not implement any device drivers,
but uses BIOS calls, which interface only to a few things like display,
keyboard, disk etc, and that most modern hardware does not even support
the standard BIOS calls.

☺/ A!ex




-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp and PilOS

[Lonnie Cumberland]

Update:   I just found some good reference documentation in the 
picolisp-25.3.tgz which will be a good start also.


Now if I can just find some documentation on the PilOS to be able to 
explore it more as well.


Thanks again

On 5/13/2025 5:18 PM, Tomas Hlavaty wrote:

On Tue 13 May 2025 at 16:12, Lonnie Cumberland wrote:

is possible to get all of this so that I can review it off-line as well?

wget -r

Re: PicoLisp and PilOS

[Lonnie Cumberland]

Hi Tomas,

Yea, I thought about that as well, but wanted to see if some of it was 
able to be downloaded first since I really like the tutorial and 
reference links which also made me think that this would be great for 
offline or local hosting to review as well, just as a thought.


Thanks again

On 5/13/2025 5:18 PM, Tomas Hlavaty wrote:

On Tue 13 May 2025 at 16:12, Lonnie Cumberland wrote:

is possible to get all of this so that I can review it off-line as well?

wget -r

Re: PicoLisp and PilOS

[Tomas Hlavaty]

On Tue 13 May 2025 at 16:12, Lonnie Cumberland  wrote:
> is possible to get all of this so that I can review it off-line as well?

wget -r

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe