00:13
zombah has quit [Quit: Leaving]
04:55
amitk has joined #linux-exynos
06:29
aballier has joined #linux-exynos
09:23
zombah has joined #linux-exynos
10:26
dlan has quit [Ping timeout: 255 seconds]
10:26
dlan has joined #linux-exynos
12:37
LanDi has joined #linux-exynos
13:20
LanDi has quit [Quit: fui !]
14:47
Tenkawa has joined #linux-exynos
14:47
Tenkawa has joined #linux-exynos
14:54
<
indy >
what is status of u-boot?
14:54
<
sjoerd >
For which board
14:54
<
Tenkawa >
not sure..
14:55
* Tenkawa
runs debian on his snow board
14:55
<
Tenkawa >
I think I'm running verified boot though
14:55
<
Tenkawa >
I still wrap my kernel
14:55
* indy
has spi flashed u-boot
14:58
<
indy >
to somehow get there new one
14:58
<
indy >
and be able boot latest kernel
14:58
<
javier__ >
indy: mainline u-boot works very well on snow, pit and pi afaict
14:59
<
javier__ >
I've been using it for some time without issues
14:59
<
sjoerd >
Having it flashed in SPI might make it behave differenlty
14:59
<
sjoerd >
Rather then puttig in on the kernel parittions
15:00
<
javier__ >
sjoerd: right, I missed that indy wanted to flash it on the SPI
15:01
<
javier__ >
maybe is relying on the ro chromiumos u-boot to do some init
15:04
<
sjoerd >
I'm also not sure whether flahsing to SPI means he replaced the RO or RW part
15:08
<
indy >
sjoerd, even you remove hw write protection, first 2mb of spi flash is still marked as ro and must be removed using chromium flashrom
15:08
<
zombah >
if this is archlinux u-boot, flashing it to spi replace both if write protection removed
15:09
<
indy >
zombah, yes it is uboot from archlinux forum
15:09
<
zombah >
its newer chromeos u-boot build, it chainloads mainline u-boot fine here
15:09
<
indy >
zombah, how?
15:10
* indy
is not against chainloading
15:10
<
zombah >
run vboot_twostop command it, its works mostly same as factory uboot
15:10
Tenkawa has quit [Remote host closed the connection]
15:10
<
zombah >
text menu asking for ctrl+u to boot custom uboot from sd/usb
15:11
<
zombah >
but becarful you need original spi backup safe, because it contain your hardware keys if you plan to use chromeos anytime ever
15:12
<
zombah >
with this custom u-boot compiled by archlinux guys, chromeos will continue work from emmc, but will not upgrade/etc
15:13
<
indy >
zombah, i made backup of spi flash before i 'crossed rubicon', but lost that backup :)
15:13
<
indy >
so it was really crossing rubicon, no way back
15:14
<
indy >
zombah, and i don't plan use chromeos
15:14
<
zombah >
indy: you can still use chromeos installed or install chromium which can work without security keys
15:15
<
zombah >
indy: its useful for tests etc, to see how hardware work there, thats only cases i use it after i have linux on snow
15:16
<
indy >
zombah, can i run chromeos from sdcard?
15:17
<
zombah >
indy: probably, i never tried myself
15:18
<
zombah >
indy: but only chromium os variant, chromeos will not install without keys partition in spi i think
15:18
<
indy >
zombah, well, my intention is to continue in 'civil war', not to cross rubicon back
15:20
<
indy >
i would like to find way to update u-boot spl and u-boot in spi to have there newest u-boot
15:21
<
zombah >
indy: boot linux from sdcard and reflash spi, you need chromeos flashrom for that
15:22
<
indy >
zombah, easily extractable from latest recovery image from google
15:23
<
zombah >
indy: you have way to recover in case of spi flashing fail?
15:24
<
zombah >
indy: if not better stay with current u-boot in spi if it work for you
15:28
<
indy >
not yet, i plan to buy soic clip
15:30
afaerber_ has joined #linux-exynos
15:30
<
zombah >
indy: then better stay with your current u-boot as first stage bootloader
15:31
<
indy >
zombah, so how to chainload it?
15:32
<
indy >
that vboot_twostop can boot also from emmc?
15:32
<
zombah >
indy: turn off, insert usb flash stich with archlinux alarm image into ehci usb port, turn on it will start to boot
15:33
afaerber has quit [Ping timeout: 252 seconds]
15:33
<
indy >
zombah, i completely removed original environment, i have only 10 environment variables
15:34
<
indy >
zombah, vboot_twostop is onetime command or i need to stop u-boot?
15:35
<
zombah >
indy: for me this u-boot always start in u-boot console unless i have disk with vmlinux.uimg inserted
15:36
<
zombah >
indy: i dont have chromebook right now, but i can share enviroments later in the evening today
15:37
<
zombah >
but as i remember there was some example setup on archlinux site
15:41
<
zombah >
indy: boot log i mean
15:42
<
zombah >
indy: line 272 is mainline u-boot start from sdcard
15:47
<
indy >
zombah, so it should also boot from emmc?
15:48
<
zombah >
indy: i have chomeos on emmc, it boots with vboot_twostop if i not interrupting it with ctrl+u, which boots linux from any external media
15:50
<
indy >
zombah, but on spi you have original chromeos firmware
15:51
<
zombah >
indy: no i have image archlinux made, the link you posted above
15:52
<
zombah >
nv_image-snow.bin
15:52
<
indy >
zombah, what you have in u-boot environment?
15:52
<
zombah >
indy: i will create paste of enviroment settings closer to midnight
15:53
<
indy >
zombah, and how you make upstream uboot image?
15:53
<
javier__ >
indy: fwiw I have the original chromiumos u-boot and created a signed FIT image with mainline u-boot
15:54
<
zombah >
indy: but better use image from some linux distro for start
15:54
<
javier__ >
indy: so the u-boot in the SPI flash loads a FIT image with mainline u-boot from the eMMC and that loads a mainline kernel
16:00
<
zombah >
bootloader image, not kernel to be sure
16:07
<
indy >
zombah, javier__ must be signed?
16:10
<
javier__ >
indy: yes
16:12
<
indy >
that's why i want mainline uboot on spi
16:12
<
javier__ >
indy: but what's wrong with signing the u-boot? there are packages with the keys on most distros
16:12
<
indy >
"it seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away. - a. de saint exupery"
16:13
<
javier__ >
and is not like you update u-boot daily
16:15
<
javier__ >
anyway, I just wanted to let you know my setup since a chain loading setup works perfectly for me
16:16
<
indy >
javier__, currently it means repartitioning emmc, therefore backup everything from home :)
16:26
zombah has quit [Quit: Leaving]
17:04
<
javier__ >
ojn: the patch "ARM: dts: Make DP a consumer of DISP1 power domain on Exynos5420" I posted yesterday fixes the error you found on peach pi and pit
17:05
<
javier__ >
ojn: it would be great if you can test it and confirm that's the case
17:06
<
javier__ >
we didn't find it before because on kernelci, the kernel doesn't panic even after the imprecise external abort error
17:07
<
javier__ >
so kernelci was reporting it as a pass
18:21
<
indy >
javier__, which .bin file i need? make snow_config && make built u-boot.bin and u-boot-dtb.bin and two bins in spl/
18:21
liquidAcid has joined #linux-exynos
18:29
<
sjoerd >
indy: -dtb.bin
18:30
<
indy >
what about those spl bins
18:35
<
sjoerd >
you don't need those if you're chainloading u-boot only if you need the spl stage
18:39
<
indy >
for cheinloading do i need to create from them uboot image using mkimage or directly use bin?
18:40
<
sjoerd >
the script zombah posted earlier does the right thing
18:53
<
indy >
it is about signing some img file
18:55
gladiac has quit [Remote host closed the connection]
19:02
gladiac has joined #linux-exynos
19:42
amitk has quit [Quit: leaving]
22:14
zombah has joined #linux-exynos
22:29
zombah has quit [Quit: Leaving]
22:35
MahNaz has joined #linux-exynos
23:29
<
MahNaz >
is it possible to find the interrupt numbers for Exynos5420 or Exynos5422?
23:35
<
liquidAcid >
MahNaz, should be somewhere in plat-samsung i guess