Hi, Thanks for taking the time to reply. This is *exactly* the kind of information I'm looking for. * Stephen Warren wrote: > Thierry Reding wrote at Thursday, October 13, 2011 11:50 PM: > ... > > I have a couple of questions, though. From what I can tell, the only > > functionality missing from mainline is nvmap/nvhost. While this is required > > for our boards, I was looking for some remote that includes support. The only > > source I came across was at git.chromium.org (kernel.git and > > kernel-next.git). I suppose those are kernels that are recommended to run on > > Tegra2 boards if HW-accelerated video decoding and 3D rendering is required, > > right? > > There are also some NVIDIA kernel repos that contain this support; see: > http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=summary > > I think our current Linux4Tegra releases do use the kernel from ChromeOS, but > future releases may move to our internal kernels. The kernel at the NVIDIA website seems to be close to what Vibrante ships with. I'll have a closer look at it. > > I guess for the time being, the best plan would be to work on two branches, > > one based on the code from chromium and one based on the mainline code which > > doesn't contain nvmap/nvhost and used to prepare patches for mainline. Which > > branch or repository should I base such work on? Olof's for-3.2 branches? > > Just as an FYI, upstreaming nvmap/nvhost isn't a near-term goal. In the longer > term, we're starting to think about a solution here. That's good news. :-) > For practical purposes, you'll probably want to base any product kernels off > one of NVIDIA's various downstream branches. Given your Vibrante usage, it'd > probably be best to ask your existing NVIDIA contacts some of these questions. > > However, please don't let that stop you upstreaming basic board support; you > should be able to upstream anything that doesn't depend on nvhost/nvmap etc. > You'll probably want to use device-tree exclusively for any new board support > in mainline. We'll have to stick to the Vibrante kernel while some issues are still being worked out and I don't want to risk any differences in the kernel to interfere. However, in the meantime I would like to prepare some board support patches for inclusion in the mainline kernel. My intention was indeed to use the device-tree exclusively. Since both boards are rather similar to Harmony, it will probably be easy to derive them from Harmony. I've been meaning to read up on device-trees for a while and this looks to be the perfect opportunity. > > Another question concerns testing. So far I've always booted a modified > > U-Boot (from Vibrante 1.1) to allow booting with an initial ramdisk (loaded > > from SD/MMC) as payload for fastboot/quickboot. What are other people using? > > Personally, I've recently switched to using mainline U-Boot on almost all my > boards (Harmony, Seaboard, Ventana). Maybe I'll add TrimSlice support there > too. Note that this relies on a number of patches that have been posted to > the U-Boot mailing list, but not yet checked into their repos. This completely > bypasses fastboot; Tegra's boot ROM runs U-Boot directly instead of fastboot. I was hoping that somebody had gotten this to work. Would you mind sharing the script that you use? All the scripts I've seen so far create some boot image (using a tool named mkbootimg) that contains U-Boot. U-Boot mainline support is another point on my TODO list. Getting the latest mainline code with the patches you mention (I assume you are referring to the patch series by Simon Glass and Tom Warren) to work would be a good step in that direction. Have you done any testing with the NVIDIA binary blobs when booting this way? The latest information I have from our NVIDIA contacts is that fastboot or quickboot are required, for some reason, to make HW accelerated video decoding and 3D rendering work. > > What tools should I be using to update the firmware? Unfortunately nvflash is > > not available in source code, and I haven't found any documentation about the > > early boot process, so it is kind of hard to figure out how all this is > > supposed to work and consequently find ways to automate these things for > > production boards. > > Try grabbing the Linux4Tegra packages from: > http://developer.nvidia.com/content/linux-tegra-release-12-alpha-1-released > > at least that has a publically obtainable/usable nvflash for a few boards. > You should be able to adjust the flash.cfg files there for other boards. > > It's a little early to say much, but there are some early movements towards > replacing nvflash with something more open for general Linux usage. More good news. > You may also want to look at the "cbootimage" tool here: > > https://gitorious.org/cbootimage That's great. Another missing piece of the puzzle. This seems to be the open-source equivalent of another tool from Vibrante that allows to create BCT files from "source" files (I've forgotten the name). Thanks, Thierry
Attachment:
pgp3q_0p3OFEV.pgp
Description: PGP signature
