On 2012-11-25, at 9:32 AM, Tim Kientzle <kient...@freebsd.org> wrote:
> > On Nov 24, 2012, at 8:01 PM, Oleksandr Tymoshenko wrote: > >> >> On 2012-11-24, at 4:47 PM, Tim Kientzle <kient...@freebsd.org> wrote: >> >> .. skipped .. >> Tim, >> >> I'm almost done with getting kernel working with latest raspberry Pi >> firmware. Just need >> to figure out how to make ubldr pass FDT pointer from u-boot to kernel and >> handle >> /reserve/ information in ARM machdep code. > > Let me know if you need help with this. I've worked with > the ubldr FDT code recently. > >> Meanwhile I suggest editing .dts file manually. Fill out "display" node >> properties with proper >> display resolution and depth. Also add ukbd driver. That should get you >> working console. > > I'll try that. > > I'm curious: why is this information coming from the DTS? > That seems pretty complex; I thought that the > console code would query this information via the mailbox > interface. It's either FDT blob or message box interface. Implementation complexity is about the same. But since we're getting other variables (like MAC address, memory size) from FDT I decided to be consistent and get all of them from there. The issue I'm facing is that ubldr gets FDT blob either from file directly or from ELF kernel itself. While on Raspberry Pi to works as follows: - Firmware loads .dtb file from SD card to specified address - Fixes up values like amount of memory, reserved regions, UART and clock frequencies, MAC address, display resolution. - Passes control to next link in boot chain (e.g. U-Boot) I'm thinking about adding compile-time constant FDT_BLOB_ADDRESS and arrange possible FDT sources in following priority: - Check FDT_BLOB_ADDRESS (if defined) - Check dtb file - Check ELF kernel Does it sound sane enough? _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
