18:48 <vagrantc> beeble: if i recall correctly, you suggested that it might be possible to use the ATF for the puma-rk3399 on the firefly-rk3399 ... would the only changes for firefly likely need to be in u-boot, or also atf/rk3399m0.bin ?

18:53 <beeble> vagrantc: iirc there are no hardware specific changes in the ATF. so it should work. you may want to have some devicetree changes as these settings get propagated into the atf (rst_gpio out of my head)

18:55 <beeble> but the atf is based on a quite old version. so it is missing features, but not sure how relevant they are for non android oses at the moment

18:55 <beeble> but the base is the same. so it should work as it is in theory

18:57 <vagrantc> is it u-boot SPL that determines what offset to load u-boot.itb from? the puma-rk3399 seemed to use a (much more reasonable) offset

18:58 <vagrantc> if i can get it working with the firefly-rk3399, i might upload an atf for and cortex-m0 stuff, as it would at least support two boards.

18:58 <beeble> the spl gets the offset from the devicetree

18:58 <vagrantc> even if it means some small divergence from upstream u-boot

18:58 <beeble> u-boot,spl-payload-offset = <0x40000>;

18:58 <vagrantc> aha

18:59 <beeble> for rk3399-puma

18:59 <beeble> take a look at config and chosen in arch/arm/dts/rk3399-puma.dtsi

19:00 <vagrantc> if i get a working atf+cortex-m0+u-boot in debian, I can enable support for those boards out of the box in debian-installer

19:00 <beeble> we try to have most things that make sense configurable via the dtb

19:01 <vagrantc> i could possibly just enable it for puma-rk3399 ... but it'd be a stronger case to make to support more than one board :)

19:01 <beeble> that sounds great

19:01 <vagrantc> though, long-term, would rather just see one ATF in Debian

19:02 <vagrantc> e.g. upstream

19:02 <vagrantc> but someone already uploaded atf-allwinner... so that bridge has been crossed :)

19:03 <beeble> having a unified atf repo will take some time, until then you will see vendor forks

19:04 <beeble> maybe someday it will be clear what should load what and who initializes what and how all these parts are exchanging informations

20:04 <vagrantc> beeble: look forward to that day :)