Re: evbarm builds failing

[Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost>]

On 2016/12/29 23:04, coypu%SDF.ORG@localhost wrote:
> armv7--netbsdelf-eabihf-mdsetimage: fs image (20480000 bytes) too big for buffer (15204352 bytes)
>
> the install kernels tend to be small and minimal... all of the
> firmware in ${DESTDIR}/libdata/firmware is for wifi and for
> radeon, I don't think it's absolutely essential. it's not
> standard hardware for RPI.
>
> Should it not install this firmware at all?

Why don't we simply increase buffer to 2MB? I'd prefer to maximize
available options for users rather than minimize the install kernels.
I agree with you if we need floppy disks to install for evbarm, but
we do not. And it is not always true that some devices are not
"standard" for evbarm just because they are not for RPI.

On 2016/12/29 23:13, Martin Husemann wrote:
> I have also seen my alpha's root disk overflow recently, and of course
> it can't use any of this (I did not yet get around to install the TC-USB
> adaptor).
>
> Maybe we should put firmware in different sets based on the bus the
> device "usually" attaches to?

Hmm, it seems difficult to distinguish which devices are available for
a given port. For example, my AlphaServer and Sun Blade have xhci port
(via PCI to PCI-E bridge), although I've not seriously tested yet ;-).

  NetBSD 7.99.43 (DS10) #2: Thu Dec  1 19:16:36 JST 2016
          rin@xxx:xxx
  COMPAQ AlphaServer DS10 466 MHz, s/n
  ...
  ppb0 at pci0 dev 15 function 0: vendor 12d8 product e111 (rev. 0x02)
  ppb0: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2.5GT/s
  pci1 at ppb0 bus 2
  pci1: i/o space, memory space enabled, rd/line, wr/inv ok
  xhci0 at pci1 dev 0 function 0: vendor 1912 product 0015 (rev. 0x02)
  xhci0: interrupting at dec 6600 irq 39
  xhci0: xHCI version 1.0
  usb0 at xhci0: USB revision 3.0

Thanks,
Rin