<Duality>
so when it worked by loading from serial via x-modem that was because i used the wrong spl lol
<Duality>
one which worked but didn't update it with my compiled one
<Duality>
that is why it worked on serial but not from mmc/emmc
urja has quit [Read error: Connection reset by peer]
urja has joined #u-boot
<Duality>
do not think it's going oversize i disabled a option in spl usb networking (which i do not use) and made the binary 88K but it still won't work when gpio-hog is enabled.
tnovotny has joined #u-boot
cpackham[m] has quit [Ping timeout: 244 seconds]
agust has joined #u-boot
<wyre>
hi guys, what are these mmcblk1boot0 and mmcblk1boot1 partitions? http://ix.io/3oDm
<wyre>
they are apparently like separate boot partitions for storing the bootloader
<wyre>
but I'm currently not using them and the system apparently works as expected 🤔
<hanetzer>
wyre: they're whatever you want them to be. I once had a setup where they were used for a u-boot-env partition, with redundancy
ad__ has quit [Ping timeout: 264 seconds]
<wyre>
hanetzer, but I can't see them in fdisk -l output
<wyre>
and they are listed like separated devices in lsblk -f output
tnovotny has quit [Read error: Connection reset by peer]
<hanetzer>
well yeah. you can almost think of them as a pair of extra disks. the partitions are set in the emmc's settings iirc. there's also mmcblk1rpmb or so. honestly no idea what that is :D
tnovotny_ has joined #u-boot
<wyre>
hanetzer, the point is that they aren't shown either in the fdisk -l output ... so I'm not sure if they are even disks
<hanetzer>
they are, effectively. you have to do some sysfs echo stuff to write to them.
tnovotny has joined #u-boot
tnovotny_ has quit [Ping timeout: 244 seconds]
<hanetzer>
and fdisk may be deliberately be skipping them. they're not the sort of 'disk' you'd write a filesystem to/partition anyways. iirc they're very small
agraf has quit [*.net *.split]
BobBeck has quit [*.net *.split]
manu has quit [*.net *.split]
mranostaj has quit [*.net *.split]
Patater has quit [*.net *.split]
bq has quit [*.net *.split]
robert__ has quit [*.net *.split]
robher has quit [*.net *.split]
ullbeking has quit [*.net *.split]
mmind00 has quit [*.net *.split]
birkoff has quit [*.net *.split]
marex has quit [*.net *.split]
ccaione has quit [*.net *.split]
angelo has joined #u-boot
monstr has joined #u-boot
monstr has quit [Client Quit]
monstr has joined #u-boot
tnovotny has quit [Read error: Connection reset by peer]
tnovotny has joined #u-boot
angelo is now known as 029AAATUB
BobBeck has joined #u-boot
mranostaj has joined #u-boot
bq has joined #u-boot
manu has joined #u-boot
Patater has joined #u-boot
birkoff has joined #u-boot
ccaione has joined #u-boot
agraf has joined #u-boot
mmind00 has joined #u-boot
robher has joined #u-boot
ullbeking has joined #u-boot
robert__ has joined #u-boot
marex has joined #u-boot
tnovotny_ has joined #u-boot
tnovotny has quit [Ping timeout: 245 seconds]
cpackham[m] has joined #u-boot
manu_ has joined #u-boot
manu has quit [Read error: Connection reset by peer]
<Duality>
some devices use it to store a bootloader and others configuration for the bootloader
<wyre>
Duality, apparently these are being ignored? 🤔
<wyre>
could I mount them to check what they have inside?
bq has joined #u-boot
<wyre>
nope, they haven't apparently any FS
<Duality>
i think they are just special places on the disk where data can be stored out side of the partitioning.
LokeshVutla has quit [Remote host closed the connection]
LokeshV_ has joined #u-boot
LokeshV_ has quit [Remote host closed the connection]
LokeshV_ has joined #u-boot
LokeshV_ has quit [Remote host closed the connection]
LokeshV_ has joined #u-boot
tucanae47 has joined #u-boot
LokeshV has joined #u-boot
LokeshV_ has quit [Ping timeout: 268 seconds]
Tazura has joined #u-boot
LokeshV has quit [Quit: Leaving]
<marex>
wyre: eMMC HW partitions
<marex>
wyre: yes, they are a separate chunk of flash for storing whatever boot stuff
<marex>
wyre: some vendors claim the blocks used for those are separate from the BBM pool of the user area
<marex>
wyre: see mmc bootbus and mmc partconf to fiddle with those
<wyre>
marex, are those commands?
<marex>
wyre: u-boot shell commands, yes
milkylainen has quit [Quit: Connection closed]
elafon has joined #u-boot
angelo_ has joined #u-boot
mvaittin has quit [Quit: node-irc says goodbye]
cpackham[m] has quit [Quit: node-irc says goodbye]
cpackham[m] has joined #u-boot
mvaittin has joined #u-boot
mvaittin has quit [Quit: node-irc says goodbye]
mvaittin has joined #u-boot
mrnuke has quit [Remote host closed the connection]
Gravis has quit [Ping timeout: 245 seconds]
Gravis has joined #u-boot
alpernebbi has joined #u-boot
torez has joined #u-boot
angelo_ has quit [Quit: Leaving]
__ad- is now known as __Ad
__Ad is now known as __ad
Guest31 has joined #u-boot
redbrain has joined #u-boot
Guest31 has quit [Quit: Client closed]
__ad has quit [Quit: ZNC 1.7.2+deb3~bpo9+1 - https://znc.in]
tprrt_ has joined #u-boot
tprrt_ is now known as tperrot
sszy has quit [Ping timeout: 245 seconds]
tperrot has quit [Quit: leaving]
tprrt has joined #u-boot
tprrt is now known as tperrot
Tazura has quit [Quit: Client closed]
tperrot has quit [Quit: leaving]
tprrt has joined #u-boot
tnovotny_ has quit [Quit: Leaving]
tprrt is now known as tperrot
vagrantc has joined #u-boot
guillaume_g has quit [Ping timeout: 264 seconds]
redbrain has quit [Ping timeout: 272 seconds]
monstr has quit [Remote host closed the connection]
Gravis has quit [Read error: Connection reset by peer]
Gravis has joined #u-boot
redbrain has joined #u-boot
Gravis has quit [Ping timeout: 252 seconds]
samueldr has joined #u-boot
Gravis has joined #u-boot
Tazura has joined #u-boot
redbrain has quit [Ping timeout: 272 seconds]
LokeshV has joined #u-boot
LokeshV has quit [Quit: Leaving]
swiftgeek has quit [Remote host closed the connection]
swiftgeek has joined #u-boot
Gravis has quit [Ping timeout: 272 seconds]
Guest38 has joined #u-boot
Gravis has joined #u-boot
redbrain has joined #u-boot
gsz has quit [Quit: leaving]
Guest38 has quit [Quit: Client closed]
Guest38 has joined #u-boot
smartin has quit [Quit: smartin]
ad__ has joined #u-boot
ad__ has joined #u-boot
ad__ has quit [Changing host]
alan_o has joined #u-boot
alpernebbi has quit [Quit: alpernebbi]
Guest38 has quit [Quit: Client closed]
redbrain has quit [Ping timeout: 252 seconds]
Tazura has quit [Quit: Client closed]
Tazura has joined #u-boot
Tazura has quit [Quit: Client closed]
Tazura has joined #u-boot
hanetzer has quit [Ping timeout: 264 seconds]
tdf has joined #u-boot
paguilar__ has joined #u-boot
paguilar_ has quit [Ping timeout: 244 seconds]
<tdf>
I'm having a strange problem with running u-boot on qemu-system-riscv64. When I run my really simple kernel straight from opensbi it runs much much faster than if I have opensbi start u-boot and then execute the kernel from there. I've tried to eliminate as many variables as I can, the kernel is mapped in memory the same way in both cases and I use