waldo323__ has quit [Remote host closed the connection]
rcn-ee has joined #beagle
Guest97987 has joined #beagle
<Guest97987>
is it possible to run any of the beagleboard images via qemu?
<GenTooMan>
I've nary tried that.
<zmatt>
Guest97987: not really, qemu has no ability to emulate an AM335x
<zmatt>
emulating a SoC to the point of having even basic functionality is a ton of work... there has been a fork/branch of qemu that had some level of support for emulating an OMAP3 iirc but that has since been abandoned and nothing similar has ever been made for any other TI SoC afaik
<rcn-ee>
Guest97987, what's your reasoning for trying this?
<zmatt>
it is possible to use qemu-user-static and systemd-nspawn to get a working shell inside a container running a beaglebone image, e.g. to install packages using APT or do configuration tasks
<zmatt>
but that doesn't boot the image
<zmatt>
Daulity: be aware that gpio numbers in linux are not actually *guaranteed* to be 32*bank+index, what actually happens is that the kernel will allocate a consecutive range of gpio numbers for every gpio controller when it is registered. though it appears to be the case that the platform gpio controllers are always registered first and it *appears* to always happen in the right order
<zmatt>
Daulity: my preferred solution for sysfs gpio is to use an udev rule to create a /dev/gpio/ directory with symlinks that allows applications to access sysfs gpios by name rather than by number
<Guest97987>
to experiment with making radical changes to the OS without the tedious reflashing process if it proves unrecoverabble
<zmatt>
Guest97987: why not just do so on SD card?
<rcn-ee>
Guest97987, why not use qemu (x86) images on your host.. there really isn't much "am335x" specific...
<Guest97987>
i didnt want wear on my already ancient 4gb sd cards more than i had to
<zmatt>
4GB is the _minimum_ sd card size
<Guest97987>
yeah i dont havve/cant get new ones
<Guest97987>
the beaglebone images are pretty different from stock debian id think?
<zmatt>
they are
<rcn-ee>
Guest97987, besides kernel and u-boot, it's debian using connman (buster), or systemd-network (with bullseye)... and some gadget loading drivers for usb-ethernet/usb-serial..
<zmatt>
I'm a bit puzzled about the "not able to get new micro SD card" part... micro SD cards are cheap and plentiful
<rcn-ee>
shitty corporate budget? ;)
<Guest97987>
i dont have money
<Guest97987>
im only using the beagleboard-o because it was 5 dollars
<Guest97987>
thats not to say i dont like it, i do
<Guest97987>
the more i explain, the more people will say why, but i dont even know why myelf
<zmatt>
the what? what device you have?
<Guest97987>
i want to experiment with replacing the init systme
<Guest97987>
among other things
<zmatt>
why would you want to do that
<Guest97987>
i have to go now
<Guest97987>
irrational hatred of systemd
<rcn-ee>
why?
<zmatt>
I'm glad you're aware it's irrational
<Guest97987>
if it was irrational, i could tell you
<Guest97987>
rational, i mean
<zmatt>
systemd is pretty nice in practice
<Guest97987>
maybe im just a bsd die hard
<Guest97987>
later gators
<rcn-ee>
Guest97987, then use freebsd.. it supports am335x. ;)
<zmatt>
it does? I know about openbsd
<rcn-ee>
or one of the bsd's..
<Guest97987>
i dont htink those boot on my beaglebone
<zmatt>
why not?
<rcn-ee>
it shows up on freebsd... i don't know if anyone's tested it a in a while..
<zmatt>
looks like openbsd might not have usb support for the beaglebone, at least it's not listed on that page
<zmatt>
you may or may not care
<zmatt>
of course if you just don't like the init system you can also use yocto
<zmatt>
"The University of Cambridge teaches its L41: Advanced Operating Systems masters-level OS course based on BeagleBone Black and FreeBSD" .. that's neat. although it appears that for 2020-2021 they replaced the BBB by an RPi4 .. boo
<zmatt>
rcn-ee: lxqt fits in eMMC again?
<zmatt>
(with any amount of free space left over)
<Daulity>
another question i have is about the bootloader but it's more of a u-boot question though If i build uboot i get a SPL this is a second program loader is it second because the rombootloader is the first?
<zmatt>
Daulity: it's just what u-boot calls it but yes
<Daulity>
and sometimes this SPL is called the first stage?
<zmatt>
it's the first u-boot stage
<Daulity>
and MLO is just the spl but it has a header on it?
<zmatt>
MLO is the (very simple) executable format used by am335x bootrom when booting from memory devices (SD/eMMC, SPI, etc)
<zmatt>
(with the caveat that u-boot also sometimes seems to produce a binary with that name that's actually an MLO with a 512-byte "configuration header" prepended)
<rcn-ee>
zmatt, it should... the "ti" extra am57xx hasn't been installed on the base lxqt image..
<rcn-ee>
Daulity, MLO naming predates "u-boot spl" by a few years...
<zmatt>
MLO is a concept of the SoC, SPL is a concept of U-Boot
<zmatt>
the format of an MLO is struct { u32 length; u32 load_address; u8 data[length]; }
<zmatt>
bootrom loads the data to load_address and then jumps to load_address in ARM mode
<zmatt>
load_address will almost always be 0x402f0400 on the AM335x
<zmatt>
(and the maximum length is 109KB)
<Daulity>
zmatt: thanks this clears up a lot! :)
<zmatt>
you might also find this interesting, it's a miniscule (964-byte) example program I once wrote that runs baremetal on the BBB, directly loaded by bootrom, and it builds it into various formats including MLO: https://github.com/mvduin/bbb-asm-demo/
<Daulity>
looks very interesting
<zmatt>
there's of course no reason to use all-assembly here, I just did that because I made this after asked for an assembly example
otisolsen70 has joined #beagle
buckket has quit [Remote host closed the connection]