Re: Running kgdb in batch mode.
On 26 November 2012 01:21, Sushanth Rai wrote: > Basically I would like to get kernel backtrace of a bunch of threads from the > live kernel under some conditions. When the condition is seen I would like to > run kgdb, collect kernel backtrace of specific threads and exit. Is there a > way run kgdb in batch mode ? Or any other way to get the stack trace. Have a look at /usr/sbin/crashinfo for an example of how to do so - basically just run kgdb $KERNEL $VMCORE < commands_file. -Ed ___ 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"
Re: FreeBSD on RaspberryPi
On Nov 25, 2012, at 11:46 PM, Oleksandr Tymoshenko wrote: > > On 2012-11-25, at 9:32 AM, Tim Kientzle wrote: > >> >> On Nov 24, 2012, at 8:01 PM, Oleksandr Tymoshenko wrote: >> >>> >>> On 2012-11-24, at 4:47 PM, Tim Kientzle 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. My thinking: * Display resolution used by kernel has to match what the firmware uses. So the kernel should either get the information from the firmware or from the same place the firmware gets it from. * We want ubldr to remain generic, so I'm reluctant to put things into it that are RaspberryPi-specific. If the firmware is putting the values into the FDT, then having the kernel get it from the FDT is another way for the kernel to get it from the firmware, so that sounds okay. > 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. I don't know about MAC address. Memory size is handled generically by ubldr using a standard interface to U-Boot, so it's not special to RaspberryPi. The FDT editing is just a standard way for ubldr to pass this to the kernel. > 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 Does RaspberryPi firmware now load an FDT? Does the firmware now read the FDT to get its values for display resolution, etc? (I don't really like this because a lot of people need to tweak the display settings and it's hard to tell a 6-year-old how to edit and recompile an FDT.) > - 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) To be clear: You say the RPi firmware is already doing this editing? So the ubldr just has to pass the RPi FDT to the kernel? If so, that's a lot simpler. > 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? If the RPi firmware always loads the FDT at a fixed address and the RPi firmware is using the FDT to configure itself, then it makes a lot of sense. It would be nice to do this without adding RPi-specific code to ubldr. > ___ > 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" > ___ 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"
Re: Running kgdb in batch mode.
On Mon, 26 Nov 2012, Ed Maste wrote: On 26 November 2012 01:21, Sushanth Rai wrote: Basically I would like to get kernel backtrace of a bunch of threads from the live kernel under some conditions. When the condition is seen I would like to run kgdb, collect kernel backtrace of specific threads and exit. Is there a way run kgdb in batch mode ? Or any other way to get the stack trace. Have a look at /usr/sbin/crashinfo for an example of how to do so - basically just run kgdb $KERNEL $VMCORE < commands_file. procstat -kk [pid] will give a kernel stack trace from userspace. -Ben Kaduk ___ 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"
Re: FreeBSD on RaspberryPi
On 2012-11-26, at 7:05 AM, Tim Kientzle wrote: > > On Nov 25, 2012, at 11:46 PM, Oleksandr Tymoshenko wrote: > >> >> On 2012-11-25, at 9:32 AM, Tim Kientzle wrote: >> >>> >>> On Nov 24, 2012, at 8:01 PM, Oleksandr Tymoshenko wrote: >>> On 2012-11-24, at 4:47 PM, Tim Kientzle 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. > > My thinking: > * Display resolution used by kernel has to match what the firmware uses. So > the kernel should either get the information from the firmware or from the > same place the firmware gets it from. > * We want ubldr to remain generic, so I'm reluctant to put things into it > that are RaspberryPi-specific. > > If the firmware is putting the values into the FDT, then having the kernel > get it from the FDT is another way for the kernel to get it from the > firmware, so that sounds okay. > > >> 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. > > I don't know about MAC address. Memory size is handled generically by ubldr > using a standard interface to U-Boot, so it's not special to RaspberryPi. > The FDT editing is just a standard way for ubldr to pass this to the kernel. > >> 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 > > Does RaspberryPi firmware now load an FDT? Yes, when requested by device_tree_address and device_tree parameters in config.txt > > Does the firmware now read the FDT to get its values for display resolution, > etc? > (I don't really like this because a lot of people need to tweak the display > settings and it's hard to tell a 6-year-old how to edit and recompile an FDT.) No. firmware writes to .dtb display's native resolution (or the one requested in config.txt) to it. Not vice versa. That's the way to pass this information to kernel. > >> - 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) > > To be clear: You say the RPi firmware is already doing this editing? > > So the ubldr just has to pass the RPi FDT to the kernel? If so, that's a lot > simpler. Yes > >> 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? > > If the RPi firmware always loads the FDT at a fixed address > and the RPi firmware is using the FDT to configure itself, > then it makes a lot of sense. > > It would be nice to do this without adding RPi-specific > code to ubldr. There will be no RPi-specific code. Just one more way to specify location of generic FDT blob. ___ 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"
Re: FreeBSD on RaspberryPi
On Nov 26, 2012, at 10:43 AM, Oleksandr Tymoshenko wrote: > > On 2012-11-26, at 7:05 AM, Tim Kientzle wrote: > >> >> On Nov 25, 2012, at 11:46 PM, Oleksandr Tymoshenko wrote: >> >>> >>> On 2012-11-25, at 9:32 AM, Tim Kientzle wrote: >>> On Nov 24, 2012, at 8:01 PM, Oleksandr Tymoshenko wrote: > > On 2012-11-24, at 4:47 PM, Tim Kientzle 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. >> >> My thinking: >> * Display resolution used by kernel has to match what the firmware uses. >> So the kernel should either get the information from the firmware or from >> the same place the firmware gets it from. >> * We want ubldr to remain generic, so I'm reluctant to put things into it >> that are RaspberryPi-specific. >> >> If the firmware is putting the values into the FDT, then having the kernel >> get it from the FDT is another way for the kernel to get it from the >> firmware, so that sounds okay. >> >> >>> 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. >> >> I don't know about MAC address. Memory size is handled generically by ubldr >> using a standard interface to U-Boot, so it's not special to RaspberryPi. >> The FDT editing is just a standard way for ubldr to pass this to the kernel. >> >>> 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 >> >> Does RaspberryPi firmware now load an FDT? > Yes, when requested by device_tree_address and device_tree parameters in > config.txt > >> >> Does the firmware now read the FDT to get its values for display resolution, >> etc? >> (I don't really like this because a lot of people need to tweak the display >> settings and it's hard to tell a 6-year-old how to edit and recompile an >> FDT.) > No. firmware writes to .dtb display's native resolution (or the one > requested in config.txt) to it. Not vice versa. > That's the way to pass this information to kernel. > >> >>> - 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) >> >> To be clear: You say the RPi firmware is already doing this editing? >> >> So the ubldr just has to pass the RPi FDT to the kernel? If so, that's a >> lot simpler. > Yes > >> >>> 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? >> >> If the RPi firmware always loads the FDT at a fixed address >> and the RPi firmware is using the FDT to configure itself, >> then it makes a lot of sense. >> >> It would be nice to do this without adding RPi-specific >> code to ubldr. > > There will be no RPi-specific code. Just one more way to specify location of > generic FDT blob. This all sounds good then. So we can put the FreeBSD .dts file on the MSDOS Boot partition, then: * Firmware will load it into memory and add display information. * ? ubldr will access the FDT and add memory information and MAC address info ? * Kernel will then load it and use it to initialize. Maybe another possibility would be to script ubldr and have it load the FDT from the correct location in memory. ubldr already knows how to load an FDT and how to pass that FDT to the kernel. Tim ___ 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"
Re: FreeBSD on RaspberryPi
On 11/26/2012 6:53 PM, Tim Kientzle wrote: This all sounds good then. So we can put the FreeBSD .dts file on the MSDOS Boot partition, then: * Firmware will load it into memory and add display information. * ? ubldr will access the FDT and add memory information and MAC address info ? Memory is somewhat complicated. memory node contains whole range of memory 256 or 512 Mb The VideoCore part is passed as memreserve table. memreserve is not real property. It's got own API calls in libfdt and does not fit nicely with generic OF framework we have in FreeBSD. So I'm kind of on a fence here: either we need merge memory regions and memreserve in FDT fixup procedure in ubldr. Or convert memreserve data to valid property in ubldr again. Or add hack to arm/arm/machdep.c, which is not really good. * Kernel will then load it and use it to initialize. Maybe another possibility would be to script ubldr and have it load the FDT from the correct location in memory. ubldr already knows how to load an FDT and how to pass that FDT to the kernel. ubldr loads FDT only from raw file or ELF kernel. We'll need "fdt addr" subcommand.But now you mentioned it, I think it might be worth adding it instead of compile-time option. ___ 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"
