<Wizzup>
D1337d: thanks for the write for the chromebook2, I'll try it after snow
<Wizzup>
btw, the guide doesn't specifically mention - but I guess the uImage of the zImage with dtb appended is good enough?
<Wizzup>
No need for a FIT image?
<D1337d>
thats correct
<D1337d>
but i checked the FIT image stuff there as i am not sure if you can boot a uImage off a block devie partition
* D1337d
will have to add a 'why you want to do it this way' to uImage and FIT' sections
* Wizzup
should look into his snow u boot
<Wizzup>
somehow everything I try for mainline fails
<Wizzup>
Need to recheck that setup...
* D1337d
found defconfig works but my custom .config did not
* D1337d
needs to track down the option preventing it from booting
<si1v3r>
I've got a peachpit here...
amitk has joined #linux-exynos
dlezcano has quit [Ping timeout: 256 seconds]
dlezcano has joined #linux-exynos
<sjoerd>
Wizzup: you can use mainline u-boot on all samsung chromebooks now btw
<HcE>
does mainline U-Boot also support 5422 well?
<HcE>
or should an U-Boot built for 5420 (most chromebooks) work fine on 5422 also?
<sjoerd>
you can build it for peach-pi
<sjoerd>
using the peach-pi config
<HcE>
hmm, sweet
* HcE
digs into code
<HcE>
what is really the difference between 5420 5422 and 5480. AFAICT it looks like speed grades.
ssvb has quit [Ping timeout: 252 seconds]
ssvb has joined #linux-exynos
<sjoerd>
I don't know the 5480
<sjoerd>
did you mean 5800 ?
<sjoerd>
But 5422 is a pretty reasonable upgrade to the 5420, has some fixes, iirc higher speed CPU's and for example a different revision of the hw decoder
<HcE>
I meant 5800, yes
<HcE>
odroid-xu3 has 5422, but there are no upstreamed implementations of it
<HcE>
stuck with an old U-Boot and kernel from hardkernel
<HcE>
it would be typical if some vital registers were offset at a slightly different location causing software to be incompatible.
<Wizzup>
sjoerd: ack, I guess I'll have to create an sd card and play around with it :)
<Wizzup>
It's just that often there are a lot of variables that are not clearly documented (as the loadaddr for tenkewa last night) that it's often a frustrating experience
dlezcano has quit [Ping timeout: 252 seconds]
<Wizzup>
sjoerd: for example, for snow, u-boot typically generates a u-boot.bin; with I guess we need to get it into some .kpart format to dd it to the partition to have chromeos load it?
<Wizzup>
although, u-boot usually has OK documentation... let me check :)
<sjoerd>
I think the documentation for that is still missin in u-boot
<sjoerd>
sending a patch for that is on my todo list
<sjoerd>
Wizzup: you need to wrap the u-boot-dtb.bin in a uboot header and then use the normal procedure to make that into a kpart
<sjoerd>
for snow that's something like that mkimage -A arm -O linux -T kernel -C none -e 0x43E00000 -a 0x43E00000 -d u-boot-dtb.bin /tmp/uboot.img
<sjoerd>
with the entry point being the expected u-boot load address
<sjoerd>
for for peach it's 0x23E00000 -
<Wizzup>
ack
<Wizzup>
And of course to complicate matters I have an encrypted rootfs and always forget where I have my proper initramfs :)
<Wizzup>
thx for the info
<sjoerd>
hehe
<sjoerd>
normally you put /boot unencrypted
<sjoerd>
mailnine u-boot can boot raw zImage and a raw initramfs so you don't need all the crap with making uImages anymore
<sjoerd>
and you can use syslinux menus for extra goodness
<Wizzup>
boot is unencrypted :)
<Wizzup>
and I just got an uImage for peach-pi to boot
<Wizzup>
(now to enable the proper cryptographic functions so I can actually boot)
<Wizzup>
ah, that's nice @ mainline u-boot
<Wizzup>
We should provide some u-boot binaries (esp. for the kpart) in the future
<Wizzup>
Save people the hassle of doing it all themselves, unless they want to (and then we need proper instructions)
<sjoerd>
I just want to package it up for debian tbh
<sjoerd>
this should all be supported by distros directly not random binaries downloaded from wherever
<Wizzup>
Wouldn't you first need documentation and a way to do it manually before distros pick it up?
<Wizzup>
(also personally don't care too much for debian, but nice if any distro picks up support)
<sjoerd>
I've got an @debian.org address so not really :)
<sjoerd>
But yeah ideally u-boot should document these things so it's easier for folks to pick up right from there
<Wizzup>
I'm from the gentoo corner
<Wizzup>
and if I want to do a setup, sometimes the kpart and compiling u-boot is a bit too much
<Wizzup>
especially if it costs hours and hours
<Wizzup>
so having a prebuilt is nice, you can focus on replacing it with youro wn later
<Wizzup>
well, now the crypt target is no longer a module ... :)
<sjoerd>
Yeah that's why we have .debs not just source code folks have to compile
<sjoerd>
I thought gentoo also had an option to get pre-compiled stuff these days, but i might be completely wrong
<Wizzup>
(not interested in philosophical differences)
<Wizzup>
gentoo has binpkg, but currently there is not even a package this kind of stuff
<Wizzup>
brb
<sjoerd>
Sounds like you want a package then :)
<Wizzup>
that does what exactly? set up all the partitions and prepare the whole setup?
<Wizzup>
but the point was not that actual compiling it takes time, but the lack of instructions and all the things that can go wrong, because u-boot can be tricky (especially for chromebooks apparently)
<Wizzup>
And if some package fails to compile or work, it's not a big deal if you already have the bootloader+kernel+X up
<Wizzup>
(on that note: didn't manage to start X on the dp-integ branch: not with modesetting and not with armsoc)