I don't see a DTB file for the eoma-pc a20 (what is the correct name for this board BTW?) in http://d-i.debian.org/daily-images/armhf/daily/device-tree/
Now that mainline kernels should work fine on this board we need a DTB. I want to try this but am just wondering if someone has already sorted a DTB before I dive in a try to make one.
It's presumably pretty close to the sun7i-a20-cubietruck.dtb or sun7i-a20-olinuxino-micro.dtb or sun7i-a20-cubieboard2.dtb dtbs?
Given a DTB we expect debian-installer to 'just work' already, but that needs testing.
Wookey
On Thu, Jun 26, 2014 at 11:38 PM, Wookey wookey@wookware.org wrote:
I don't see a DTB file for the eoma-pc a20 (what is the correct name for this board BTW?)
it actually needs dynamic creation based on: * a "base" DTB * kernel-time detection of the I2C EEPROM * reading of a board-specific DTB file from the I2C EEPROM * merging of the "base" DTB with the board-specific DTB.
Now that mainline kernels should work fine on this board we need a DTB. I want to try this but am just wondering if someone has already sorted a DTB before I dive in a try to make one.
feel free but please bear in mind the above, that the identity *changes* depending on the base-board that the CPU card is plugged into. i've spoken to alan cox already and he's suggested for there to be a bus/eoma68 subdirectory plus lib/eoma68 subdirectory to cover the shared code across different CPU cards and base-boards.
l.
it actually needs dynamic creation based on:
- a "base" DTB
- kernel-time detection of the I2C EEPROM
- reading of a board-specific DTB file from the I2C EEPROM
- merging of the "base" DTB with the board-specific DTB.
The two middle points could be done by u-boot, since u-boot already adjusts the kernel's dtb in many cases (e.g. to provide the amount of RAM available).
Stefan
On Fri, Jun 27, 2014 at 1:50 PM, Stefan Monnier monnier@iro.umontreal.ca wrote:
it actually needs dynamic creation based on:
- a "base" DTB
- kernel-time detection of the I2C EEPROM
- reading of a board-specific DTB file from the I2C EEPROM
- merging of the "base" DTB with the board-specific DTB.
The two middle points could be done by u-boot, since u-boot already adjusts the kernel's dtb in many cases (e.g. to provide the amount of RAM available).
ah! good point. and... wait... hang on... *thinks*.... there are circumstances where suspend, unplug, resume...
... no, it really does have to be handled by the kernel - hopefully u-boot would not need to do much (if anything).
ok, first suggestion: wookie, would you be happy to do the "base" DTB, basically set up a DTB which is in effect booting the CPU Card from USB-OTG, with UART, USB, Ethernet and RGB/TTL LCD enabled? ignore GPIO (they can change).
l.
+++ Luke Kenneth Casson Leighton [2014-06-27 15:03 +0100]:
On Fri, Jun 27, 2014 at 1:50 PM, Stefan Monnier monnier@iro.umontreal.ca wrote:
it actually needs dynamic creation based on:
- a "base" DTB
- kernel-time detection of the I2C EEPROM
- reading of a board-specific DTB file from the I2C EEPROM
- merging of the "base" DTB with the board-specific DTB.
The two middle points could be done by u-boot, since u-boot already adjusts the kernel's dtb in many cases (e.g. to provide the amount of RAM available).
ah! good point. and... wait... hang on... *thinks*.... there are circumstances where suspend, unplug, resume...
... no, it really does have to be handled by the kernel - hopefully u-boot would not need to do much (if anything).
ok, first suggestion: wookie,
wookey - you should know by now :-)
would you be happy to do the "base" DTB, basically set up a DTB which is in effect booting the CPU Card from USB-OTG, with UART, USB, Ethernet and RGB/TTL LCD enabled? ignore GPIO (they can change).
Yes, I'll try to make a DTB that boots my card in my holder. Once that's working we can look at what a more complete solution looks like.
How many DTB-different holders are actually available currently?
And what should we call the DTB file(s)?
Wookey
On Fri, Jun 27, 2014 at 3:47 PM, Wookey wookey@wookware.org wrote:
+++ Luke Kenneth Casson Leighton [2014-06-27 15:03 +0100]:
On Fri, Jun 27, 2014 at 1:50 PM, Stefan Monnier monnier@iro.umontreal.ca wrote:
it actually needs dynamic creation based on:
- a "base" DTB
- kernel-time detection of the I2C EEPROM
- reading of a board-specific DTB file from the I2C EEPROM
- merging of the "base" DTB with the board-specific DTB.
The two middle points could be done by u-boot, since u-boot already adjusts the kernel's dtb in many cases (e.g. to provide the amount of RAM available).
ah! good point. and... wait... hang on... *thinks*.... there are circumstances where suspend, unplug, resume...
... no, it really does have to be handled by the kernel - hopefully u-boot would not need to do much (if anything).
ok, first suggestion: wookie,
wookey - you should know by now :-)
doh!
would you be happy to do the "base" DTB, basically set up a DTB which is in effect booting the CPU Card from USB-OTG, with UART, USB, Ethernet and RGB/TTL LCD enabled? ignore GPIO (they can change).
Yes, I'll try to make a DTB that boots my card in my holder. Once that's working we can look at what a more complete solution looks like.
awesome.
How many DTB-different holders are actually available currently?
pffh. one, with 5 needing funding to turn into real products within 6 weeks, and another... 20 planned.
And what should we call the DTB file(s)?
argh think eoma68-a20-base. that makes it clear that it's not the "full" DTB.
arm-netbook@lists.phcomp.co.uk
-
Luke Kenneth Casson Leighton -
Stefan Monnier -
Wookey