Cool, the fixed memory on the beta board fixed the issue i was seeing
on the alpha with loading.. "dra7-ipu2-fw.xem4" (Android video
acceleration codec's).. On the alpha, it would just hardlock...
Yeap! I need to change that. The image shares the same base rootfs
that we use for the beaglebone's. I need to tweak the /etc/hosts when
i make it for a specific board..
Works: Alpha board
2GB
Line Audio out/in [1]
HDMI video
HDMI audio [2]
USB
RTC[3]
SATA[4]
Palmas power button[5]
emmc[6]
Sweet! Thanks for testing all those!
It looks like either i messed up a config, or reset might be broken:
debian@beaglebone:~$ uname -r
3.14.26-ti-r43
debian@beaglebone:~$ sudo reboot
Starting Reboot...
[ 35.335196] reboot: Restarting system
(2 led's lit)
Kernel:
synced with: bdea111134d82dc225f16f69652284f684985aee (top of the branch)
With that I was able to reboot some 5 times. that makes me
wonder...two things:
a) On the current X15, ES1.1, warm reset is supposed to be routed to
PORz sequence for Palmas -> should'nt it setup everything properly by
Palmas? maybe we ought to monitor the rails and figure that out.
b) ES1.2 will have warm reset fixed, so we'd go back to hitting the
same issue all over again :(...
maybe we need something like a boot-device dt property to not reset
pins..
I see that similar attempt like https://patchwork.kernel.org/patch/5480691/ was tried as well.. which
kinda results in the same problem but the solution for gpio expander
obviously wont for for x15 (as it has no gpio expander).
Since this might even be valid for SATA boot (powering off SATA might
result in SATA not detected by ROM code since ROM code does not talk
to PMIC anymore and depends on boot configuration).
we might want to restore something like boot-configuration for a
shutdown handler and depend on PMIC powering everything off for
poweroff. uggh... sounds like a wider forum question here.. will let
someone(kishon/roger?) take the ball to linux-kernel lists with a
proposal perhaps?